Scaling Postgres to the next level at OpenAI
summary
OpenAI runs an unsharded Azure Database for PostgreSQL primary with many read replicas and migrates write-heavy workloads off-system, using PgBouncer to avoid a hard 5,000 connection limit and cut connection latency from 50ms to <5ms. Rate limiting on query digests and connection creation, dedicated replicas for high‑priority traffic, strict schema rules (only nullable columns, no table rewrites, concurrent index changes), timeouts like idle_in_transaction_session_timeout plus statement and client timeouts, and pg_stat_activity checks for blockers keep reads fast and avoid SEV0s.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:35Background – how Postgres was scaled to meet demand at OpenAI
- 4:02Challenges in write-heavy workloads
- 5:49How read-heavy workloads are served by unsharded Postgres
- 6:19Reduce load on primary
- 9:09Query optimization
- 11:58Single point of failure
- 15:03Rate limit
- 17:46Connection pooling
- 19:53Schema management
- 23:40Wrap-up
related talks
51mScaling Postgres to the next level at OpenAI
36mPostgres at any Scale
50mUnleashing the Power of Azure for PostgreSQL
40mPushing past PostgreSQL’s vertical scaling limits - Running Amazon RDS
37mPostgres at Any Scale
13mBuilding reliable infrastructure with Postgres
24mAll The Postgres Things at Microsoft, POSETTE edition
58mScaling Postgres