5 ms·

Just use https://github.com/yandex/odyssey https://github.com/yandex/odyssey :) It's a scalable PgBouncer.

by x4m 3mo ago

sevg 3mo ago
Fun (semi-related) fact, ClickHouse was originally developed by Yandex :)
saisrirampur 3mo ago
We started with the most battle-tested and native option to Postgres, which is PgBouncer and tried tuning it the right way. Also now that long due kinks like support for prepared statements are solved, it’s been working really well. There are many customers scaling well with 10K+ Postgres connections. We will consider other options like odyssey, pgdog in the future! Side note: I’m not a big fan of having 10K+ connections on Postgres, 100s are more than enough to scale Postgres well. But that’s a story for another day. ;)
- hinkley 3mo ago
  > 100s are more than enough to scale Postgres well I'd want to know what the workload is. That's true of lots of projects, especially internal tools (even for multinationals). But for my last project, that would have been tough. And by FAANG standards my last project was 'medium' sized, even though it was large by the standards of many places I've worked. (The galling thing is I shrunk the hardware by 40% but if I'd been there during the architecture phase I'm pretty sure I could have shrunk it by 8x by solving a completely different problem that had higher margins than what we actually did)
- x4m 3mo ago
  With Odyssey we have customers with 50k+ connections operating normally. Also consider SQPR - it's a connection pooler with sharding capabilities. It handles data migration between shard on top of request routing. Odyssey will inherit this capability once it is stable enough in functions set.
deleted 3mo ago
[deleted]
Yajirobe 3mo ago
yandex is a russian company, so no, don't use it
- khuey 3mo ago
  I have bad news for you about where ClickHouse comes from then.
- chews 3mo ago
  thank you for the advice mr mcarthy, i'll happily use deepseek and GLM to vibe my next project.
- inigyou 3mo ago
  Do you boycott American companies too? I'm assuming you boycott Russian companies because Russia causes death and destruction. But the USA caused much more death and destruction than Russia ever did - do you boycott them too?
  - mgfist 3mo ago
    uhhhh
  - Yajirobe 3mo ago
    [flagged]
    - UnfitFootprint 3mo ago
      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-diplomacy-and-dependence/106647598 https://www.abc.net.au/news/2026-05-08/russia-nuclear-power-...
      - Yajirobe 3mo ago
        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.
functional_dev 3mo ago
is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it
- x4m 3mo ago
  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.
- mmakeev 3mo ago
  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

Just use https://github.com/yandex/odyssey https://github.com/yandex/odyssey :) It's a scalable PgBouncer.

by x4m 3mo ago

Just use https://github.com/yandex/odyssey https://github.com/yandex/odyssey :) It's a scalable PgBouncer.

sevg 3mo ago

Fun (semi-related) fact, ClickHouse was originally developed by Yandex :)

saisrirampur 3mo ago

We started with the most battle-tested and native option to Postgres, which is PgBouncer and tried tuning it the right way. Also now that long due kinks like support for prepared statements are solved, it’s been working really well. There are many customers scaling well with 10K+ Postgres connections. We will consider other options like odyssey, pgdog in the future! Side note: I’m not a big fan of having 10K+ connections on Postgres, 100s are more than enough to scale Postgres well. But that’s a story for another day. ;)

hinkley 3mo ago
> 100s are more than enough to scale Postgres well I'd want to know what the workload is. That's true of lots of projects, especially internal tools (even for multinationals). But for my last project, that would have been tough. And by FAANG standards my last project was 'medium' sized, even though it was large by the standards of many places I've worked. (The galling thing is I shrunk the hardware by 40% but if I'd been there during the architecture phase I'm pretty sure I could have shrunk it by 8x by solving a completely different problem that had higher margins than what we actually did)
x4m 3mo ago
With Odyssey we have customers with 50k+ connections operating normally. Also consider SQPR - it's a connection pooler with sharding capabilities. It handles data migration between shard on top of request routing. Odyssey will inherit this capability once it is stable enough in functions set.

deleted 3mo ago

[deleted]

Yajirobe 3mo ago

yandex is a russian company, so no, don't use it

khuey 3mo ago
I have bad news for you about where ClickHouse comes from then.
chews 3mo ago
thank you for the advice mr mcarthy, i'll happily use deepseek and GLM to vibe my next project.
inigyou 3mo ago
Do you boycott American companies too? I'm assuming you boycott Russian companies because Russia causes death and destruction. But the USA caused much more death and destruction than Russia ever did - do you boycott them too?
- mgfist 3mo ago
  uhhhh
- Yajirobe 3mo ago
  [flagged]
  - UnfitFootprint 3mo ago
    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-diplomacy-and-dependence/106647598 https://www.abc.net.au/news/2026-05-08/russia-nuclear-power-...
    - Yajirobe 3mo ago
      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.

functional_dev 3mo ago

is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it

x4m 3mo ago
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.
mmakeev 3mo ago
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