Hacker News Reader

Comment by conradludgate | Hacker News Reader

(I work on the postgres proxy layer at Neon)

PgBouncer is entirely optional and it's not always the right choice. If you have a classical app (non serverless) and you can maintain a connection pool from your app, then I recommend avoiding pgbouncer.

The benefits of pgbouncer mostly come from irregular client connections (too many, too much churn). If you don't have that problem, go direct to postgres.

I'm exploring replacing pgbouncer with an alternative (maybe home grown) at the moment. Mostly for multi-tenancy and HA reasons. Pgbouncer has been good for us, but it's limited in how we can deploy it in a multi-tenant environment.

View on HN

Also some people with use cases that shouldn't need PgBouncer end up thinking they do because something else is misconfigured. This was brought up in a parent of https://news.ycombinator.com/item?id=49019695; FastAPI recommends dep-injecting transactions into your HTTP handlers. Ties up all your connections and creates idle xact spam. There are valid reasons to use PgBouncer, this isn't one.

Even on serverless platforms like Heroku, I've been fine giving each worker a pool such that max_workers * pool_size < max_connections.

That’s ok if the number of workers is bounded and small. But if you’re operating on the order of hundreds to thousands of workers, maybe not so much.

Can you add more on why Pgbouncer is limited in a multi-tenant environment?

pgbouncer runs as a single threaded service, so it ends up getting bottlenecked by some heavy clients on typical server CPUs with low clock speeds.

Sharding/peering pgbouncer works, but it's not perfect.

More significantly for us is that Neon has millions of databases in each region, and thousands get created/destroyed every hour. Managing the pgbouncer config and shared connection pools will be extremely tricky to balance. We have a bunch of logic for this in the proxy I maintain, but not in pgbouncer.

The main intent is to incorporate a pooler directly into our existing proxy service to avoid needing double proxy services. We just need to find the right pooler implementation (and one that works in async Rust)

And the only comment in this whole thread, who argues for a similar architectural alternative...is the ONLY one in the whole thread down voted. HN continue to excel in technical chops...

https://news.ycombinator.com/item?id=49319988

https://news.ycombinator.com/item?id=49320460

Unless I'm missing something, your linked comments seem to be responding only to the title of the article, without addressing any of the actual points being made in the body of the article?

Lol, linking your own comments is pretty weird

Reply on news.ycombinator.com