Hacker News Reader

Comment by suchire | Hacker News Reader

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

View on HN

Another 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.

Schema 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

Our 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.)

Reply on news.ycombinator.com