What is the recommended way to handle connection pooling when there will be a small fixed set of database users (eg: 2) connecting?
For example, the two users may be: `app`: the main user used by the application with full r/w privs `readonly`: limited SELECT-only user for running SQL passed through the server api With both users only actually used locally by the server app. With the connection credentials being in the connection string passed to create_engine(), does this limit the way of managing this to creating two independent engines? It seems that going with two engines also means two sessionmakers and two connection pools. The server application would then grab the appropriate session/connection based on the required operation (or app-level user account). I don't really see a problem with this, but am wondering if there is an alternative/better way (while maintaining pooling). The only minor "issues" I can drum up are 1) double the initial engine setup cost (one time), and 2) two independent pools that aren't sharing a max pool size. I'm pretty sure that neither will really matter much, though. For the independent pool "issue" I looked into pgbouncer for comparison, and it seems that it manages independent pools per (db, user) as well, so one would presume that that method isn't horrific. Then again, you still occasionally see recommendations for pool sizes at (2*cpu_count + spindle_count) so I don't know. Definitely premature optimization thoughts that can be ignored, I imagine. Russ -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
