Distributed PostgreSQL
The internals of a horizontally scalable distributed PostgreSQL: sharding, distributed query execution, two-phase commit, and moving shards while the cluster serves.
- Status
- active
- When
- 2026–
- Stack
- cpostgresqllibpqdistributed systems
- Code
- not public yet
What it is
A database engine that spreads one logical table across many machines. Rows are assigned to shards by a partitioning rule, shards are placed on worker nodes, a coordinator plans and executes queries across them, and a transaction that touches shards on more than one node commits with two-phase commit so the nodes cannot disagree about whether it happened. The same public space as Citus, if you want a reference point.
What I work on
Described at the level I can talk about publicly.
The shard lifecycle: the operations that extend, retire and rebalance ranges while the cluster is serving traffic. I rewrote that layer, folding a few thousand lines of user-defined functions into one operation model with cutoff expressions and scheduling that knows which kind of operation it is running. Every operation now has a dry run: an operator sees what it would do to live cluster metadata before a single shard is mutated, so a wrong plan is caught before it changes anything.
A read-only consistency verifier for the cluster: fifty checks over shard placement, colocation, replication residue, two-phase-commit state and node health, fanning out to every node asynchronously with a deadline per node so one sick node cannot hang the run. Each finding is fingerprinted, so the same defect keeps the same identity across scheduled runs instead of looking new every night. It is modelled on PostgreSQL’s amcheck, and like amcheck it is allowed to read and nothing else.
A logical-decoding output plugin that reads the write-ahead log and emits each row change as a JSON record, honouring the row filters and column lists a publication declares, with a background worker beside it reporting throughput per replication slot.
Underneath all of it: the write-ahead log, MVCC and tuple visibility, heap and B-tree storage, distributed transaction recovery, shard pruning and distributed query planning. Mostly C, mostly under LLDB across a multi-node cluster.
What I have learned
That the interesting cases are all failure cases. A distributed commit is easy to describe and hard to recover; the useful findings from a consistency checker are the ones that stay failing for weeks until someone works out why; and a dry run is worth more than a rollback, because by the time you want a rollback the metadata has already moved.
Status and what’s next
Current work. The generic PostgreSQL knowledge it forces me to learn ends up in the PostgreSQL internals, explained simply series; the product-specific design does not appear here.