758 stars · PostgreSQL License · no GitHub releases · Track this in Scout
An add-on that lets several PostgreSQL databases all accept changes and keep each other in step.
▶Repo detailsthe review · specs · pros & cons · install
What it does
It installs as a PostgreSQL extension, which is extra code loaded into the database itself rather than a separate program. Each database becomes a node, publishes the changes it accepts, and subscribes to the changes from the others. It uses PostgreSQL's own logical decoding, so changes travel as rows rather than as raw disk blocks, which is what allows nodes to run different major versions. It resolves a collision — the same row changed in two places at once — by keeping the change with the later timestamp, and it records what it discarded so the choice can be audited. It can replicate a chosen set of tables rather than everything, and it keeps sequences from handing out the same number twice on two nodes. The README states support for PostgreSQL 15 through 19. It is not a sharding tool and not a load balancer: every node holds the whole of the replicated data, and something else has to send each client to a nearby node.
Why it matters
Who it suits. Anyone whose users are in more than one part of the world and who can no longer accept the delay of writing to a single place. It also suits anyone who needs to move between major PostgreSQL versions with almost no downtime, because the two versions can replicate to each other while traffic moves across. Skip it unless multi-place writing is a real requirement, because a single primary with read-only copies is far less to run and far less to reason about.
Verdict. The most specialised entry in this edition, and genuinely impressive for 758 stars. It is alive in the strongest sense available: code was pushed on 23 October 2026, the day before this edition, and the README already covers a PostgreSQL version that is not finished yet. There are no releases on GitHub, which is one of today's four. The warning is the honest one about this whole technique: letting two places both accept changes means accepting that some conflicting change will be thrown away, and a last-one-wins rule is a decision about data, not a technical detail. Read how collisions are resolved and logged before deciding, not after. The licence is the PostgreSQL License, which is short and permissive. For the neighbouring, simpler case of one writer and many readers, 2ndQuadrant/pglogical is the older relative; for splitting one large database across machines rather than copying it, citusdata/citus is the different answer.
- Several places can all accept changes, which no stock PostgreSQL setup allows.
- Nodes may run different major versions, so a big upgrade can happen with the lights on.
- Short, permissive licence, and the company behind it publishes the whole extension.
- Last-change-wins means conflicting edits are discarded, and that is a choice about data.
- Compiling and loading an extension is a different level of work from installing a program.
- 758 stars, so there are few public write-ups and almost no community answers to search.
- 2ndQuadrant/pglogical
The older extension this family grew from, which copies changes from one writer to many readers; its maintainers now put new work into a commercial descendant.
Track this in Scout - citusdata/citus
AGPL-3.0, splits one large table across many machines and runs queries in parallel, which is a different problem from letting several places accept changes.
Track this in Scout
git clone https://github.com/pgEdge/spock cd spock make sudo make install
