pgbouncer runs as a single threaded service, so it ends up getting bottlenecked by some heavy clients on typical server CPUs with low clock speeds.
Sharding/peering pgbouncer works, but it's not perfect.
More significantly for us is that Neon has millions of databases in each region, and thousands get created/destroyed every hour. Managing the pgbouncer config and shared connection pools will be extremely tricky to balance. We have a bunch of logic for this in the proxy I maintain, but not in pgbouncer.
The main intent is to incorporate a pooler directly into our existing proxy service to avoid needing double proxy services. We just need to find the right pooler implementation (and one that works in async Rust)
Comments
pgbouncer runs as a single threaded service, so it ends up getting bottlenecked by some heavy clients on typical server CPUs with low clock speeds.
Sharding/peering pgbouncer works, but it's not perfect.
More significantly for us is that Neon has millions of databases in each region, and thousands get created/destroyed every hour. Managing the pgbouncer config and shared connection pools will be extremely tricky to balance. We have a bunch of logic for this in the proxy I maintain, but not in pgbouncer.
The main intent is to incorporate a pooler directly into our existing proxy service to avoid needing double proxy services. We just need to find the right pooler implementation (and one that works in async Rust)