@Azure: Scale PostgreSQL reads the easy way. In #AzureFriday, @shanselman and Paula Berenguel show how PostgreSQL Flexible Serv…

Scale PostgreSQL reads the easy way. In #AzureFriday, @shanselman and Paula Berenguel show how PostgreSQL Flexible Server uses read replicas and virtual endpoints for heavy read workloads.

Watch now: https://t.co/tGKvvqCGhm https://t.co/dowBQRHNMw

TL;DR: Read-heavy PostgreSQL workloads on Azure Database for PostgreSQL Flexible Server can be scaled easily with read replicas — up to 30 per primary — following the same pattern that powers ChatGPT.

ChatGPT runs on Postgres

Scott Hanselman opens the episode skeptical that scaling Postgres could be simple. His guest, Paul, has a surprising fact to share:

The most surprising thing is that most people don’t know the database behind ChatGPT is actually Postgres. It has one primary and read replicas — no sharding, no fancy distributed engine.

Scott is genuinely surprised: he assumed ChatGPT — “the world’s computer” — would run on something far more exotic than the same technology powering his own site. Paul clarifies that ChatGPT is, to a large extent, supported by Postgres, and more importantly, the pattern OpenAI uses is one any developer can apply to their own projects.

The pattern: one primary for writes, replicas for reads

Paul’s core point: developers forget that applications read far more often than they write. When read traffic grows and CPU spikes, the instinct is to reach for sharding, distributed databases, or a completely different technology. But with Azure Database for PostgreSQL Flexible Server — and Postgres in general — the simplest answer is usually read replicas.

In this pattern:

• The primary node handles writes.
• Read replicas scale out reads.

Demo architecture: a primary in UK South, replicas across Europe

The demo architecture mirrors how OpenAI serves GPT users. The primary is deployed in UK South, with replicas distributed across Europe. Paul chose Italy North and Spain Central in the demo, but he stresses that you are not limited to regional placement:

Don’t limit yourself to replicas in Europe. They can be in Australia. They can be in the US. In this case I’m just trying to imitate OpenAI’s way of serving GPT users — by continent, bringing the data closer to the actual users.

Three replicas are deployed for the demo, but that’s just a fraction of what’s possible.

Virtual endpoints: failover without changing connection strings

The demo also includes a virtual endpoint, a feature Paul says people often overlook. Its main purpose is failover: if a disaster forces you to switch the primary to one of the replicas, the application doesn’t need to change anything. The app transitions seamlessly to the new primary and keeps operating.

This is one of those things people overlook, and a question I get a lot from customers: “How do I achieve cross-region failover in Azure without changing my application connection strings?”

Paul is clear about one limitation: you cannot currently use a virtual endpoint to load-balance across all replicas. That, too, remains the application’s responsibility.

How fresh are the replicas? Replica lag

Scott asks the practical question: if he writes to the primary in UK South and immediately reads from a replica in Spain Central, what is the latency? Milliseconds? Seconds? Days?

Paul’s answer: replicas — even cross-region ones, even as far away as Australia — should stay within single-digit seconds of lag, usually under 10 seconds. The actual lag depends on two factors:

• Distance between the primary and replica
• Write volume — the pressure on the primary

In practice, it’s typically a few seconds.

Read-your-writes consistency is an application concern

Scott pushes further: what if his application needs immediate access to data it just wrote? Is there a Postgres setting that gives fast access, or is this an application-layer problem?

Paul confirms it’s an application-layer problem. Some applications can tolerate the small delay in exchange for the benefits of reading from replicas. Others can’t:

If they must read right after committing — immediately see what they committed — they usually have to keep that read/write functionality on the primary, or you need to consider another solution.

The good news: out of the box, an application needs to do nothing to benefit from replication. All the replication work is handled by Postgres Flexible Server.

Creating replicas in the Azure portal

Paul walks through the portal, where everything is pre-configured for the demo — but creating a replica on your own is straightforward. In the Replication tab, you can:

• Choose a replica region (e.g., Italy North, Spain Central)
• Select the replica size — you can create replicas with higher or lower specs than the primary
• View the replication phase
• Check the current lag time

The portal view is also handy for showing management that replication is working. This is the same place you configure virtual endpoints.

Scott connects the dots: replicas aren’t just for disaster recovery and regional outages — they’re a performance tool. A virtual read connection string can route a Spanish user to the right database in Spain. He compares replicas to a CDN for his database:

You write something to the CDN, wait 5 to 10 seconds, and now it’s available all over the world. This looks a lot like that.

Paul agrees.

Demo part 1: hammering the primary

To show the value of replicas, Paul first sets up a baseline workload that does everything against the single primary in UK South. The benchmark app simulates a typical chatbot:

• Retrieving your sessions
• Searching within a session
• Creating a new session for a user

The workload is read-heavy, with some writes mixed in. When the baseline script runs, the primary’s CPU climbs. Paul zooms into the Azure portal chart — one-minute granularity — and the CPU hits 97%.

To be clear, at this point the replicas exist but are completely idle. It’s as if they don’t exist at all. The scenario demonstrates what happens when you run everything on one Postgres primary.

Demo part 2: offloading reads to replicas

Paul stops the baseline app — which had executed 37,000 queries in 257 seconds. In a real application you wouldn’t stop anything; you’d just point your reads at a replica. But in the demo, he runs a switch script that routes:

• Writes → UK South primary
• Reads → read replicas

The setup includes 6 readers and 4 writers, triggering roughly 80 to 170 queries per second.

Back in the Azure portal, the primary’s CPU starts dropping — it still handles writes, but the read pressure is gone. The replica’s CPU, meanwhile, rises as it serves the application’s read requests. And you can spread that load even further across additional replicas if needed.

That’s how you relieve pressure on the primary and free up space for more functionality, higher performance, and greater scalability — all with Flexible Server.

How far can you scale? 30 replicas, and replicas of replicas

Scott asks the obvious follow-up: he can have as many replicas as he wants, placed in regions all over the world — just like ChatGPT does?

Yes, you can have up to 30 replicas.

Paul then explains the tiering:

The first tier can have 30, and each of those first-tier replicas can have five more.

Realizing the implications, Scott asks how multi-tier replication works. In this scenario, if the Azure Friday primary is in UK South, you can navigate to a replica’s replication page and create five more replicas underneath it.

Oh, really? It’s replicas of replicas.

Paul confirms — replicas of replicas — and cautions that if one of the regions in the chain goes down, the entire replica chain is affected.

The takeaway

Scaling reads on Postgres doesn’t require a distributed database or a migration to a new technology. With Azure Database for PostgreSQL Flexible Server, you can keep a single primary for writes, add read replicas around the world, and handle enormous read traffic — up to 30 replicas in the first tier, each of which can have five more. The same pattern that backs one of the most heavily used applications on the internet is available to any developer, today, through the Azure portal.

Source: Scale PostgreSQL reads the easy way | Azure Friday