Connection pooling: 5 real scaling case studies
5 of the 73 engineering write-ups in our database are tagged with the technique "connection pooling". They come from 4 companies (OpenAI, Figma, Shopify and Supabase) and were published between 2023 and 2026. Stack that shows up most often in these stories: PostgreSQL (3) and Cosmos DB (2). Often combined with query optimization (2), rate limiting (2) and read replicas (2). 4 of the 5 state concrete scale numbers, for example "70 million+ requests/sec" (OpenAI). Each card below links to our short summary and the original post.
Rapidly scaling online storage to serve over 1 billion ChatGPT users
OpenAI's Habitat storage platform grew from a Python client library over Cosmos DB into a central service handling 70M+ requests per second. The team ran many low-concurrency Python processes to keep asyncio delay down, switched aiohttp connection reuse from LIFO to FIFO to stop a metastable failure, used Envoy for connection fan-in, kept a deliberately simple NoSQL API, then rewrote the service in Rust.
We replaced Redis with MySQL for inventory reservations—and it scaled
Shopify moved checkout inventory reservations from Redis to MySQL using one row per sellable unit, a bounded pool of 1,000 rows per item/location and SELECT ... FOR UPDATE SKIP LOCKED. The real ceiling was connections held by other checkout code: tagging SQL by business process and measuring hold time in ProxySQL found it, and the cleanup removed 50% of reads and 33% of transactions on the primary.
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.
Supavisor: Scaling Postgres to 1 Million Connections
Supabase load-tested Supavisor, its Elixir Postgres pooler, with a million client connections.
The growing pains of database architecture
How Figma moved from one Postgres instance to multiple databases by vertically partitioning table groups.