3 ms·
is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it
by 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 agoAs 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 agoI 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