Use gunicorn in the Docker image? Uvicorn not advised in prod about chroma HOT 4 CLOSED

The main difference between Gunicorn and Uvicorn (as I understand it) is that Uvicorn is best as a single-worker model whereas Gunicorn has better performance and support for multiple workers, where each worker is its own python process.

So on a "traditional" server where you want parallel request processing by multiple isolated workers, Gunicorn or a Gunicorn+Uvicorn combo is going to perform better.

But if we're contemplating an MVP where the primary "hot" representation of the data is in-memory, then we can't have multiple workers, because multiple processes don't share memory. We'd end up with N diverging in-memory representations if we did that.

So Gunicorn only becomes relevant in a world where we have a "stateless" FastAPI server that's writing through each request to some shared-state persisted database incrementally. Which relates to the question you asked in #38 and does somewhat depend on the capabilities of DuckDB to support overlapping updates from multiple processes.

from chroma.

Close relation to #38 - definitely agree.

from chroma.

We could move forward with this now I believe. @levand

from chroma.

Moving to backlog

from chroma.