4 ms·
I lean on client-side pooling these days. It works and is easier to reason about for me, e.g. this client process gets 2 connections. Specifically knex has clie
by sojournerc 5y ago
I lean on client-side pooling these days. It works and is easier to reason about for me, e.g. this client process gets 2 connections. Specifically knex has client pooling.
Provides good back pressure and hasn't fallen down yet. Any reason not to do it this way?
- manquer 5y agoIf you have lot of client sources (say in each micro service) different languages and frameworks connecting to same server ( perhaps different db/schema ). It is easier then to manage it in one place . Also dynamic scaling of server pools etc you need change the pooler config instead of every application. And postgres connection management(open/close) is expensive, if you can handle it outside the the db infra it can be beneficial ( only some client libs will pool their connections and others won't). Even with client pooling support in the library, each container/forked runner will have its own connection, and that can be quickly few hundreds. Finally AFAIK most libraries don't handle master failover or server restart without crashing the connection, pooler will usually keep the upstream open for some time.