Imagining OpenAI’s 800-million-users PostgreSQL at scale without replicas or offloading, on RegattaDB

In January, OpenAI engineer Bohan Zhang published "Scaling PostgreSQL to power 800 million ChatGPT users". It is excellent engineering. A single primary PostgreSQL instance on Azure, with nearly 50 read replicas, serves "millions of queries per second for 800 million users." It is also an unusually candid account of where that architecture runs out of room, and it closes by saying the team will keep exploring "sharded PostgreSQL or alternative distributed systems, as our infrastructure demands continue to grow."

This post takes five constraints the article describes, in OpenAI's own words, and shows how a distributed SQL database, RegattaDB, approaches each one. RegattaDB was built from scratch to run transactions, analytics and vector search in a single engine, from one node to clusters of thousands of nodes.

1. Reads are scaled by copying the database

OpenAI's workload is read-heavy: "Since our workloads are primarily read-heavy, and we've implemented extensive optimizations, the current architecture still provides ample headroom to support continued traffic growth." The way to serve that many reads from PostgreSQL is to copy data over the network to replicas on other nodes. Each replica holds a full copy of the entire database and replays every write the primary makes, so with nearly 50 replicas the same data is stored, and the same writes are applied, about 50 times over. That results in a system-wide 50x write amplification for each write. Each replica is another instance to provision, pay for and keep in step with the primary, and a replica of this kind trails the primary it copies.

With RegattaDB, reads, as well as writes, scale linearly by adding nodes to the same cluster. Every node serves queries on current live data, so there is no replica fleet to build, no write amplification, and no copy to fall behind.

2. Only one machine can write

The OpenAI article is direct about the limit: "With only one writer, a single-primary setup can't scale writes. Heavy write spikes can quickly overload the primary and impact services like ChatGPT and our API." OpenAI's solution is to keep the primary as free as possible: "We minimize load on the primary as much as possible—both reads and writes—to ensure it has sufficient capacity to handle write spikes." On writes, it says: "For write traffic, we've migrated shardable, write-heavy workloads to sharded systems such as Azure CosmosDB. Workloads that are harder to shard but still generate high write volume take longer to migrate, and that process is still ongoing." Ironically, the need to replicate each write to many destinations makes the load on the primary even higher. Not only does one node need to serve all the writes, but it also needs to work meaningfully harder on each such write in order to replicate it to the destinations.

Even this solution creates many additional challenges. Reads have to be pushed out to replicas, yet some must still stay on the primary. Write-heavy workloads have to be moved to a second database, and the ones that are hard to shard are still being migrated.

With RegattaDB, transactions execute across many nodes, with serializable ACID guarantees across the whole cluster. Writes are spread across the entire cluster and are not forced to be executed by a single node. Therefore, adding nodes adds write capacity, and a spike is absorbed by the cluster instead of landing on one machine. Write-heavy workloads can also stay in the same database, instead of moving to a separate system such as Cosmos DB.

3. Replicas cannot be added indefinitely

Every replica adds work for the primary: "As the number of replicas increases, the primary must ship WAL to more instances, increasing pressure on both network bandwidth and CPU." Every write has to reach, and be replayed by, every replica. And: "we can't keep adding replicas indefinitely without eventually overloading the primary." OpenAI's answer is cascading replication, where intermediate replicas "relay WAL to downstream replicas," an approach that "allows us to scale to potentially over a hundred replicas without overwhelming the primary." It is a clever fix, but it also adds a replication topology to operate and debug.

With RegattaDB, there is no single primary shipping its log to a growing fan-out of copies. Write capacity grows with the nodes in one cluster, so this ceiling, and the cascade built to push it back, do not arise.

4. Sharding is the usual escape, and it is expensive

Why not shard PostgreSQL? "The primary rationale is that sharding existing application workloads would be highly complex and time-consuming, requiring changes to hundreds of application endpoints and potentially taking months or even years."

Application rewrite is not the only cost. Sharding a single-node database has trade-offs of its own, and it often breaks what developers expect from ACID. Our whitepaper, Dirty Secrets of Sharding, covers them.

With RegattaDB, the application sees one logical SQL database. The system spreads data and work across nodes, so there are no shard keys to design and no application endpoints to rewrite for the database to scale.

5. MVCC makes heavy writes expensive

Even where writes are possible, each one is costly inside PostgreSQL. The article explains why: "Although PostgreSQL scales well for our read-heavy workloads, we still encounter challenges during periods of high write traffic. This is largely due to PostgreSQL's multiversion concurrency control (MVCC) implementation, which makes it less efficient for write-heavy workloads. For example, when a query updates a tuple or even a single field, the entire row is copied to create a new version. Under heavy write loads, this results in significant write amplification. It also increases read amplification, since queries must scan through multiple tuple versions (dead tuples) to retrieve the latest one. MVCC introduces additional challenges such as table and index bloat, increased index maintenance overhead, and complex autovacuum tuning."

With RegattaDB, RegattaDB's MVCC implementation is very different from PostgreSQL's as well as from other relational databases. Whenever a row has multiple row-versions (i.e., tuple versions) a query can immediately read the right tuple version, without needing to scan through all the row's row-versions. Furthermore, RegattaDB's Ranger technology allows cleaning of the row-versions that became unneeded (i.e., dead tuples) in an extremely efficient manner, without needing awkward and wasteful mechanisms such as PostgreSQL's VACUUM that effectively needs to crawl the entire database, seeking for those unneeded row-versions.

If you run PostgreSQL at a scale where replicas have become their own project, we would like to hear from you at regatta.dev.

Source: Bohan Zhang, "Scaling PostgreSQL to power 800 million ChatGPT users," OpenAI, 22 January 2026, https://openai.com/index/scaling-postgresql/. All quotations are from that article.