Using SQLAlchemy connection pool with different deployment environment

Question

I have been reading the SQLAlchemy documentation on connection pooling, while the topic is by itself simple; I think it has lots to do with how you deploy your application (I'm talking about a WSGI application here).

Lately I'm starting to use Gunicorn. It has several workers types. Currently I'm using only synchronous workers: those that "that handles a single request at a time".

So in this scenario, would be best to use a StaticPool, i.e a single reutilizable connection per worker? Or does SQLAlchemy could attempt to make several connections even in the case of an synchronous worker? - assuming that the application itself does not use threads.

Answer 1

There's every reason just to stick with the default of QueuePool:

1. QueuePool only opens as many connections as it's asked to at at time. If your app uses only one connection at a time, that's the only connection your app will open.

2. SQLAlchemy itself never opens additional connections beyond what you tell it to (anything that requires database access is basically going to use a single connection to access the DB. like create_all(), or Session.query().whatever. It only uses one connection at a time.).

3. if your app does happen to have some kind of thing that incurs more than one connection at a time, such as, using two Session objects at once, or perhaps calling engine.execute() when you are still fetching the results from another engine.execute(), QueuePool will set up that second connection without any issue. Whereas StaticPool will use the same connection and then you'll get issues.

4. If you really want to make sure your app is using one and only one connection per process, you can look into AssertionPool - this is more of a debugging/test pool though, not necessarily one that we've used at scale. Or set up QueuePool with pool_size=1 and max_overflow=0, which would basically lead to a deadlock if you try to open two connections at the same time in one thread....