Hacker News Reader

Comment by jhgg | Hacker News Reader

at work we run pgbouncer on 4 vCPU (GCP c2-standard-4) machines, at 60% load, and they do ~15k TPS at peak, however we only peak at ~45k connections per node.

however, i think that you may have a lot left on the table in terms of optimizations that can be made. these numbers seem far under the performance of what i know beam to be capable.

View on HN

Hey, from what we’ve seen up to 50k per node should be ok for supavisor on 4 cores as well. And TPS is here mainly to demonstrate that we not only create dummy connections but that these connections are really used. And 20k TPS is just the maximum amount that database node was able to handle. To bump tps we had to spin up more db replicas. We want to run these tests as well at some point, but now were just verifying that we can connect millions of clients and with some tangible tps but not overcomplicating the setup too much.

Nice! Yeah really our first go at it so I’m sure we have room to improve.

PgBouncer was on the same instance I’m assuming?

nah we run a pool of common pgbouncers that route to the various postgres instances we run. they also run google's cloud sql proxy as well. it's actually haproxy -> pgbouncer -> cloud sql proxy -> postgres.

everything but postgres runs on one machine. we use haproxy to load balance replica connections across different pgbouncer backends for replicas of the same db.

Ha! Wait but why Google Cloud SQL proxy too?

If you are interested in connecting over this it would be great to connect… chase@supabase.com.

We want to do load balancing too. Makes so much sense to do load balancing in the proxy.

cloud sql proxy makes connecting to cloud managed postgres instances pretty simple/easy. honestly, we dont have a "great" reason other than, we set it up a long time ago, and it's continued to work haha.

so pgbouncer connects to cloud sql proxy, which does the connection pooling concern.

Reply on news.ycombinator.com