The Last Brick: Horizontal Write Scaling Is Coming to EDB Postgres® AI

With sharding in EDB Postgres AI Distributed, you get more scale with the same engine, same groups, and same high availability. A decade after building logical replication into Postgres with BDR 1.0, the team behind it is adding the one thing replication never gave you: write scale.

Your business growth shows up in your database as writes. Every new customer, every transaction, and, now, AI agents working around the clock add more. Eventually those writes outgrow a single server. Horizontal scaling, coming to EDB Postgres AI (EDB PG AI), spreads them across groups of servers that each keep their own automatic failover, so you add capacity to the cluster you already run instead of migrating to a new database, keeping cost and overhead down as your business grows.

In August 2016, a small team released BDR 1.0, the first production multi-writer logical replication for Postgres. The pieces it stood on, logical decoding and replication slots, went into Postgres core a couple of years earlier, built by the same people. Ten years later, that lineage is in EDB PG AI Distributed (PG AI Distributed). It runs critical systems for which a lost commit is a regulatory event: hundreds of financial institutions, one production cluster of 250 nodes, 70+ TB in a single cluster.

In those 10 years, distributed Postgres solved three problems: surviving failure, operating without maintenance windows, and putting writes close to users across geographies. It never solved a fourth one: write throughput.

For 20 years, our industry learned to scale reads. Caches, replicas, CDNs … the web was mostly people looking at things, and we got very good at serving them. AI agents change the ratio. An agent doesn’t browse, it acts. It updates an order, posts a payment, records what it decided and why. Every action is a write, and agents don’t sleep. The bottleneck of the next decade isn’t how fast you can read your data. It’s how fast your system of record can accept change.

Today’s challenge: The write ceiling

Replication scales reads, not writes. In a standard Postgres deployment, and in a standard distributed cluster too, every node applies every write. Adding nodes buys you durability and failover headroom, but no extra write throughput.

Most systems never hit that ceiling, though always-on workloads are bringing it closer. The ones that do (payment authorization, core ledgers, high-ingest telemetry, large multi-tenant SaaS) have had two options. Either buy bigger servers and eventually hit a limit, or leave Postgres for a different engine with a Postgres-shaped front end. That means giving up the extensions, tooling, and operational knowledge your team spent years building. For a regulated enterprise, that second option is more than an engineering project. It's a recertification program, with new controls, new audits, new failure modes to explain to a regulator. That can take longer than the growth it was meant to serve.

Now, EDB is building horizontal write scaling directly into PG AI Distributed, so you don’t have to make that trade.

What we’re announcing

Horizontal scaling works in PG AI Distributed by sharding, so that data is split across shard groups. Each group owns a slice of the rows and handles the writes for that slice in parallel with the others. For example, a bank with 500 million customers can shard its data on customer ID across 10 groups. PG AI Distributed hashes each customer ID to decide which group owns that customer, so each group holds roughly 50 million customers. A write to one customer’s account goes only to the nodes in that customer’s shard group, not to every node in the cluster. Adding shard groups raises the write ceiling.

The first build is a technical preview now in the hands of the customer design partner we’re building this with. General availability for sharding is planned for February 2027.

We’re announcing before GA on purpose. If you’re approaching a write ceiling, you don’t need to leave Postgres to get past it. You stay on Postgres and on the platform you already run: always on, always sovereign, and now able to scale out as your workloads grow. If you’re on single-server Postgres today, the path starts with distributed high availability.

See it in action

The demo below shows a banking workload split across shard groups. Each customer’s transactions commit inside their own group, so the groups work in parallel instead of queueing on one server, and a node failure in one group doesn’t interrupt the others.

We’re running internal benchmarks now and will share results when horizontal scaling reaches general availability. Preview-stage numbers are easy to misread, and we look forward to publishing results we can stand behind.

The design decision: A shard is a group

If you run PG AI Distributed, you already think in groups. A cluster is a group of groups. Today the child groups usually stand for places: a region, an availability zone (AZ), a data center. Each one has its own Raft consensus subgroup, its own write leader, its own Connection Manager routing, and its own commit-scope defaults.

A shard group is one more kind of child group. Instead of holding a full copy of the data, it owns a defined slice of the rows. Everything else it inherits:

• Raft and failover. Each shard group elects its own write leader. Lose a node and that group fails over in place, in seconds. The other shard groups aren’t consulted and don’t notice.

• Commit scopes. Majority protect inside a shard group means exactly what it means anywhere else. The stricter options stay available for the transactions that warrant them.

• Connection Manager. The same routing and pooling that already runs inside the Postgres process gains one input: which shard the session is for.

• Lifecycle. Rolling upgrades, online DDL, monitoring views, the runbooks you already have. Per shard group, same playbook.

We didn’t add a coordinator tier, a new consensus layer, or a separate catalog hierarchy. Per-shard high availability isn’t bolted on. It comes with the group.

I’ve started describing it this way: Distributed Postgres has always been one architecture deployed in stages. Stage one is a single data group for local high availability (HA). Stage two adds regions as further groups for global active-active. Stage three adds shard groups under the same top-level group for write scale. Nothing you configured in stage one stops applying in stage three. It isn’t a second architecture. It’s the last brick of the architecture you’re already standing on.

For your business, scale becomes an operation, not a migration. The team, runbooks, monitoring, backups, and failover procedures you have today carry over to every shard group. There’s no second database to buy, no second operating model to learn, and no migration project between you and more capacity.

Other approaches to scaling Postgres writes make different trade-offs. Unlike coordinator-based sharding or distributed SQL engines, there’s no coordinator in the write path and no replacement storage engine: It’s the Postgres engine, with high availability for every shard, running wherever you need it.

How it works: Standard Postgres DDL

A distributed table is a hash-partitioned table with one storage option set:

CREATE TABLE orders (

    order_id    bigint NOT NULL,

    customer_id bigint NOT NULL,

    amount      numeric(12,2),

    PRIMARY KEY (order_id, customer_id)

) PARTITION BY HASH (customer_id)

  WITH (pgd.table_distribution = 'distributed');

Two rules apply: The table is partitioned by hash on a single column, and its primary key includes the shard key. That’s the whole change to your schema. Your drivers, extensions, and tools stay the same.

PG AI Distributed places rows using native Postgres hash partitioning. On each node, the partitions for the shards that node’s group owns are ordinary local tables; the rest are foreign-table stubs pointing at the owning group. Native partition pruning does the shard selection, so there is no bespoke router in the query path. Small reference tables, like product catalogs or currency codes, stay replicated everywhere as they are today, so joins against them stay local.

Routing

The fast path is to route each transaction to the group that owns its data. In the preview, the application sets the shard key once per session with  bdr.target_shard_key, and Connection Manager routes it to the write leader of the group that owns the data. From there it is an ordinary local write.

A write that lands on a group that doesn’t own the row still succeeds, over a slower path: It commits locally and is applied on the owning group, with read-your-writes preserved inside the transaction. Cross-shard reads work too, over the foreign-data path.

Where the boundary sits

Inside a shard group, you get full high availability and durability guarantees. Between shard groups, there is no global snapshot. That trade-off is deliberate, and it’s why the shard key is the most consequential schema decision you’ll make.

Who this is for

Sharding adds real operational complexity. Reach for it when the write ceiling is the constraint you actually have. That ceiling shows up in two ways: a single server that is saturated after you’ve already tuned it, or storage that can’t absorb the write volume no matter how many cores the server has. Spreading writes across shard groups, each with its own storage, addresses both.

Good fits:

• Payments, core banking, and other high-volume transaction systems, where most activity belongs to one customer or account (customer_id or account_id), and related tables share the key and joins stay in one group.

• Multi-tenant SaaS keyed on tenant_id, so each tenant’s data and traffic live together.

• High-ingest time series keyed on device_id to spread writes evenly.    

When a simpler option fits better:

• Mostly reads, few writes. Add read-only subscriber nodes instead. They’re far simpler to run.

• Most queries need all of the data at once. Queries that reach every group will dominate response times.

• Heavy reporting and analytics. Keep them off the transactional path with subscriber nodes or by integrating with object storage or WarehousePG for analytics.        

What’s next

This preview supports a fixed number of shard groups set at deployment time, but more is coming as we approach GA with our next release in February 2027. We plan to support adding shard groups to a running cluster and online rebalancing onto the new groups. 

Getting involved

Horizontal scaling is in preview now. If you can see write growth or a ceiling ahead, here’s where to start:

• Check whether writes are your constraint. If more read replicas or a bigger server haven’t fixed it, or your team already shards in the application, sharding is worth a look.

• Pick candidate shard keys. Look for an ID with many unique values that most transactions share, such as customer, account, tenant, or device ID.

• Talk to us before GA. Your EDB account team, or pm@enterprisedb.com, can review your workload and design your shard key with you. The shard key isn’t something you change later, so that conversation is worth having now.    

Ten years ago the question was whether Postgres could carry a system of record. Nobody asks that anymore; we at EDB know it, and enterprises around the world are using it today. The question now is what happens when it succeeds, and the writes keep coming and workloads keep growing. Sharding is our answer, so Postgres grows with you.