Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We scaled PgBouncer to 4x throughput

clickhouse.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: We scaled PgBouncer to 4x throughput

#11

Post by saisrirampur »

x4m wrote: post #6

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

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

Re: We scaled PgBouncer to 4x throughput

#14

Post by levkk »

JustSkyfall wrote: post #7

I've been using pgdog ( https://github.com/pgdogdev/pgdog ) and it has worked really well for my needs!

Glad you like it. It was built to fix some of PgBouncers shortcomings that we ran into at Instacart many years ago, and to have a stronger foundation for scaling Postgres horizontally (that's sharding)!

Re: We scaled PgBouncer to 4x throughput

#16

Post by jauntywundrkind »

JustSkyfall wrote: post #7

I've been using pgdog ( https://github.com/pgdogdev/pgdog ) and it has worked really well for my needs!

It's been a pong pong back and forth between PG reverse proxy submissions lately! "Why we built [Pgdog]": https://news.ycombinator.com/item?id=48819308

Re: We scaled PgBouncer to 4x throughput

#19

Post by saisrirampur »

bradfitz wrote: post #18

I'm 46 now. I remember being shocked at Postgres's heavy connection model when I was 23. I gather things haven't improved since?

It improved quite a lot! It scales pretty well to thousands of connections: https://techcommunity.microsoft.com/blog/adforpostgresql/imp....

However, if pooling isn’t used, there’s always an overhead (tens of milliseconds or more) when creating a new connection because Postgres needs to fork a process. And yes, applications can be written without pooling, which isn’t ideal, but happens quite a lot.

Application frameworks have also changed. Serverless architectures can generate tens of thousands of connections, which is where Postgres starts to run into issues. I’m personally not a big fan of using more than a few hundred connections, but it is very realistic in this era.

Re: We scaled PgBouncer to 4x throughput

#20

Post by toredash »

saisrirampur wrote: post #10
nosefrog wrote: post #3

Interesting. We run pgbouncer via kubernetes so it was straightforward to make multiple pgbouncer processes on one machine. Also straightforward to get them running on multiple machines, which helps because we run on Azure and they like to cause rolling outages across our fleet via VM maintenance...

Ack, makes sense. I’m very curious on how this affects throughput due to a potential extra network hop from pgbouncer to Postgres. Expecting it to have a minor difference, but still curious.

Cross zone latency has noticeable effect: https://news.ycombinator.com/item?id=45512351
Post reply on HN