5 ms·
It’s pretty easy to exhaust a DB if you have many replicas of a service connecting, each at high concurrency. 20 replicas at 20 connections each is enough to hi
by suchire 5y ago
It’s pretty easy to exhaust a DB if you have many replicas of a service connecting, each at high concurrency. 20 replicas at 20 connections each is enough to hit limits (like on Cloud SQL for GCP)
As you say, you can write a service to stand in front of the DB and mediate access, but PgBouncer is already written AND production ready
- potamic 5y agoAnother reason you would want a service in front is for schema management. I suppose it depends on the use case at hand. Also, 20 connections per service process seems pretty high. Unless there are many long running queries and clients are willing to wait long times for responses.
- suchire 5y agoSchema management is not too hard at small numbers of devs. We have a monorepo and a well defined data access layer in the monolith, so simple migrations, grep, unit tests, and frequent deploys are enough to handle 99% of needs The harder part is ensuring people don’t hold onto connections during long-running operations. In some client libraries, it’s easy to accidentally hold one open. That plus autoscaling results in ticking bombs that are hard to catch with automated tests
- derefr 5y agoOur backend can open hundreds/thousands of DB connections per service process. Those queries take ~100ms to ~3s to run. Is that "long-running?" It seems average to me — complex OLAP queries are the comparative advantage of RDBMSes like Postgres, after all. (These queries are not CRUD operations, certainly.)