Just use https://github.com/yandex/odyssey :) It's a scalable PgBouncer.
is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it
We scaled PgBouncer to 4x throughput
61–67 of 67 posts
Re: We scaled PgBouncer to 4x throughput
#62Just use https://github.com/yandex/odyssey :) It's a scalable PgBouncer.
is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it
As Odyssey maintainer, I have to admit that it is exceptionally difficult to achieve stability (e.i. quality) of PgBouncer.
It has two limitations: it is single threaded and it is developed only re-actively. PgBouncer docs used to say that prepared statements can never be supported, in 2022 we supported it in Odyssey and then PgBouncer implemented it too.
In a sense Odyssey is developed to motivate PgBouncer development. To provide alternatives that keep PgBouncer from stagnation.
Yet, I can't say that scalability with SO_REUSEPORT is a good solution.
Re: We scaled PgBouncer to 4x throughput
#63is this for microservice scenarios where you gate access to the psql server through a connection pool thing? because if there is monolithic backend this is not needed. most decent backend frameworks have built-in connection pooling. that covers 98% of use cases for which microservices are not needed, nor recommended.
if your backend app is one big binary per host? Sure. But if your backend app is a shared nothing fork of many processes then this is surely needed.
didn't that end with the cgi era? what is going on :)
Re: We scaled PgBouncer to 4x throughput
#64Just use https://github.com/yandex/odyssey :) It's a scalable PgBouncer.
is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it
I have choose pgbouncer for my small db, because it does one thing and does it good - transaction pooling, other solutions seemed too complicated for me. All that features which should keep you allow to use listen/notify and set was unnecessary for me, i solved it on code level
Re: We scaled PgBouncer to 4x throughput
#65PgBouncer works great for us with Vercel Workers. We use ClickHouse PG behind it, and haven't had any issues so far :)
Re: We scaled PgBouncer to 4x throughput
#66The connection-pooler-as-bottleneck story is so common and so under-discussed,
nice writeup. Did the 4x come mostly from the multi-process model, or did you also
have to change how the app holds connections? The app-side pattern usually eats
half the gains.
Re: We scaled PgBouncer to 4x throughput
#67Earlier quoted context omitted.
except for perhaps… a scalable pg bouncer? And good nuclear reactors [1]? Not to say I support many Russian political moves, but I think discrediting an entire people and their outputs on Russian politics is brusque - particularly open source ones. [1]: https://www.abc.net.au/news/2026-05-08/russia-nuclear-power-...
Neither pg bouncer nor nuclear reactors are unique inventions in and of themselves - these are just iterations on what has existed previously. Of course russia can take an existing thing and iterate on it (computers, rockets, AK-47, etc.) but that wasn't my point.
Was a flight to space an iteration?