OpenAI published a breakdown of how it scaled PostgreSQL to serve 800 million ChatGPT users at millions of queries per second.
The company used four techniques: read replicas to spread query load across multiple database copies, aggressive caching to reduce how often queries reach the database at all, rate limiting to stop runaway requests from overwhelming the system, and workload isolation to prevent expensive operations from starving lightweight ones. None of these are novel ideas. What OpenAI did was apply them at a scale most organizations will never encounter - and make them stick. The database itself did not change; the infrastructure around it did.
The conventional move at this scale is to abandon relational databases for distributed systems built to spread load horizontally. OpenAI's choice to push PostgreSQL further instead is worth noting. It keeps the team on familiar ground, avoids a costly and risky migration, and lets them lean on decades of PostgreSQL reliability and tooling. The boring call is sometimes the defensible one.
This post lives on OpenAI's engineering blog, which doubles as a recruiting pitch. It tells you what worked. It does not tell you what failed, what approaches they tried and abandoned, or how many engineering hours it took to get here. That is not a knock - it is the nature of every infrastructure write-up that also serves as a case study.