How teams scaled PgBouncer: 3 real case studies
3 of the 73 engineering write-ups in our database mention PgBouncer in their stack. They come from 3 companies (Datadog, Notion and OpenAI) and were published between 2023 and 2026. It's often paired with PostgreSQL (3). 2 of the 3 state concrete scale numbers, for example "800 million users" (OpenAI). Each card below links to our short summary and the original post.
Scaling PostgreSQL to power 800 million ChatGPT users
OpenAI runs ChatGPT on a single-primary Postgres with nearly 50 global read replicas. Reads are offloaded, write-heavy shardable workloads move to Cosmos DB, and PgBouncer, cache leasing and multi-layer rate limits keep the primary safe.
Breaking up a monolith: How we're unwinding a shared database at scale
Datadog is splitting its large shared Postgres database into team-owned instances in three phases. Logical separation moves tables into about 30 private domain schemas with explicit ACLs, using query samples and interviews with 30+ teams. Access reduction routes services through per-team PG Proxies so ACLs can be narrowed safely, and physical separation replicates each schema to a managed OrgStore instance, moves reads first and then writes with under five seconds of downtime, and replicates back for rollback. Two workloads have fully migrated and more than 70 dead tables were deleted along the way.
The Great Re-shard: adding Postgres capacity (again) with zero downtime
Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.