Postgres-XL was a distributed fork of PostgreSQL that aimed to bring transparent sharding to the world’s most popular open-source database. It is no longer actively developed, but the ideas it pioneered live on in Citus, in the modern managed-sharding layer of the major cloud providers, and in the way most engineering teams think about scaling a relational database.
Table of contents
- What Postgres-XL was
- How the architecture worked
- Why it lost
- Where the ideas live now
- What to use instead
- FAQ
What Postgres-XL was
Postgres-XL was a fork of PostgreSQL 9.x that re-architected the storage layer to support horizontal scaling. The data was partitioned across multiple nodes; the queries were distributed across the nodes; the result was stitched together by a coordinator.
The pitch was: keep the SQL, keep the relational model, scale horizontally. The reality: keep the SQL, lose some of the features, gain a distributed-systems problem the team did not have before.
How the architecture worked
Three node types:
- Coordinator (GTM). Routes queries to the data nodes, manages transactions across nodes, returns the stitched result.
- Data nodes. Store the actual rows, partitioned by a sharding key the team picks.
- Global transaction manager. Tracks distributed transactions and provides global snapshot isolation.
The team ran at minimum 1 GTM, 2 coordinators (for HA), and 2-3 data nodes per shard. The smallest reasonable deployment was 5-7 nodes.
Why it lost
Three reasons Postgres-XL lost to the alternatives:
- The feature gap with upstream PostgreSQL grew. Every new PostgreSQL feature (logical replication, partitioning, JSONB operators) had to be re-implemented in the fork. The fork fell further behind every year.
- The operational complexity was high. Running 5-7 nodes for a single logical database was more work than most teams could afford. The team needed to know distributed-systems debugging to operate the cluster.
- The managed alternatives caught up. Amazon Aurora, Google Cloud Spanner, CockroachDB, Citus on top of a single PostgreSQL node - all of them offered the same horizontal-scaling story without the operational complexity of running the fork.
Where the ideas live now
The ideas live in three places:
- Citus. A PostgreSQL extension that adds distributed-query support without forking the database. The team can use stock PostgreSQL, install the extension, and get the same horizontal-scaling story.
- Managed sharding on the major clouds. Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL - all of them now offer some form of managed sharding.
- NewSQL databases. CockroachDB, YugabyteDB, TiDB - all of them offer the same SQL-and-scale story that Postgres-XL was reaching for, with the operational simplicity of a single managed service.
What to use instead
The decision tree in 2026:
- If you are under 500 GB and under 200 connections: a single PostgreSQL node, possibly with read replicas. This covers most workloads.
- If you are 500 GB-5 TB or 200-2000 connections: Citus on top of a single PostgreSQL node. The extension is mature, the operational story is straightforward, and the team can keep using stock PostgreSQL.
- If you are over 5 TB or over 2000 connections: a managed sharding layer (Aurora, Spanner) or a NewSQL database (CockroachDB, YugabyteDB). The team is going to need to know distributed-systems debugging no matter what they pick.
The right answer depends on the workload. The team that is choosing between a fork and a managed service is almost always better off with the managed service - the operational complexity of running a fork is a tax the team pays forever.
FAQ
What was Postgres-XL?
A distributed fork of PostgreSQL that aimed to bring transparent sharding to the open-source database. It is no longer actively developed, but the ideas it pioneered live on in Citus and the major managed-sharding services.
What replaced Postgres-XL?
Citus (a PostgreSQL extension), managed sharding on the major clouds (Aurora, Spanner), and the NewSQL databases (CockroachDB, YugabyteDB, TiDB) all offer the same horizontal-scaling story without the operational complexity of the fork.
Should I use Postgres-XL in 2026?
No. The fork is no longer maintained, the feature gap with upstream PostgreSQL has grown, and the managed alternatives offer the same capabilities with less operational overhead.
What is the difference between Citus and Postgres-XL?
Citus is a PostgreSQL extension that adds distributed-query support to stock PostgreSQL. Postgres-XL was a fork that re-implemented the storage layer. Citus is the modern choice; the team can keep using stock PostgreSQL.
If you are sizing a database tier for a new project, the RunxBuild hosting calculator is the place to model the line items. The database, the replicas, the storage, the I/O - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the production database in one place.