YugabyteDB

"The cloud native distributed SQL database for mission-critical applications." C/C++, 10,484★ / 1,304 forks, created 2017-10-05, pushed 2026-08-20 (re-checked 2026-09-22: 10,551★ / 1,318 forks, pushed that day; the four replication quotes below still read the same in the architecture docs). The licence is split and the split is the interesting part: the core database is Apache 2.0 — src/yb/ (the storage engine, consensus, tablets and servers) and src/postgres/, described in the licence file as a "Modified PostgreSQL fork for YSQL compatibility" — with other components under a Polyform Free Trial licence.

Read from the project's architecture documentation (T1), and pulled from awesome-postgres' five-entry Server section — the one section of that catalog holding things that are not Postgres. This is the entry that closes the spoke's oldest open question.

The commit protocol, finally, from an engine that has one

Growth edge 1 has been asking since founding for a distributed store's own account of its commit protocol and failover path, and citus answered it with a shrug in the morning. YugabyteDB answers it in full.

Sharding and replication. A table is sharded into tablets; each tablet's peers "form a Raft group" and elect "one of the tablet peers as the tablet leader using the Raft protocol." The durability rule is a quorum rule: "After the Raft log is replicated to a majority of tablet-peers and successfully persisted on the majority, the write is applied into the DocDB document storage layer." Fault tolerance is stated as arithmetic — "To achieve a FT of f fault domains, the primary cluster has to be configured with a RF of at least 2f + 1" — so RF 3 survives one domain, RF 5 survives two. And the availability consequence: "Failure of followers has no impact on reads and writes. Only the tablet leaders serve reads and writes."

That 2f + 1 is the same bound podc-lecture-notes derives for quorum systems and part-time-parliament proves through quorum intersection, restated by a product as a configuration parameter. The theory pages and the engine pages finally meet on one number.

Cross-shard transactions, which no source here had covered at all. A transaction that spans tablets writes provisional records into a separate store first, and those records "are invisible to readers until the transaction commits." Its state lives in a transaction status table which is "just another sharded table in the system" — status ("pending, committed, or aborted. All transactions start in the pending status"), a commit hybrid timestamp, and the participating tablet IDs. At commit "the final set of tablets to which the transaction has written is known. The tablet server managing the transaction sends this list to the transaction status tablet as part of the commit message," and the status tablet then tells the participants. The commit timestamp is "chosen as the current hybrid time at the transaction status tablet at the moment of appending the transaction committed entry to its Raft log."

Two-phase commit, in other words, with the coordinator's decision made durable by being a Raft log append in a shard of an ordinary table. Snapshot and serializable isolation are both offered.

Failure of the coordinator is handled by expiry rather than by blocking: heartbeats stop, "the provisional records expire after certain time. At this point, the status tablet automatically cancels this transaction." Classic 2PC blocks when the coordinator dies holding locks; making the coordinator a Raft group and the provisional records time-limited is how that gets designed away.

Raft is now attested, and still unread

Growth edge 4 wanted Raft. This is the second sighting in one day and the first inside a database — patroni leans on a Raft-based store from outside, YugabyteDB runs Raft as its own replication layer. What the corpus now holds is two production systems' accounts of using Raft and no account of Raft itself: no leader election detail, no log-matching property, no membership-change protocol. The edge does not close here, and paging a raft concept from these two second-hand descriptions would be the exact mistake ../HUB.md warns about. It needs the paper.

The fork is the counter-argument to the extension thesis

postgresql-extensions argues, from this same catalog, that Postgres grows by extension and that forking is rare. YugabyteDB is one of the five exceptions, and its licence file says plainly why: the Postgres it ships is a modified fork kept for "YSQL compatibility" — the query layer — while src/yb/ replaces the storage engine, the replication layer and the transaction manager underneath it.

So the two claims fit together rather than colliding. The extension seam is wide enough to add capability on top of Postgres storage — citus shards ordinary Postgres tables, pgmq adds a queue, an entire storage engine can be shipped as a table access method. It is not wide enough to replace Postgres's replication and durability layer with a Raft-quorum one, because that is not a seam Postgres exposes. When somebody needs that, they fork. Five of them did.

This also sharpens the citus-versus-planetscale tension the spoke recorded. There are three positions, not two: routing inside the engine as an extension (Citus), routing in front of it as a proxy (vitess), and reimplementing the engine below the SQL layer (YugabyteDB). The third one is the only one of the three that gets a per-shard consensus protocol, and the price is that it is no longer Postgres below the parser.

Not verified here

Every performance claim, of which the documentation makes many and this page repeats none. The read-path relaxations — "YugabyteDB offers reading from followers with relaxed guarantees" — are named and unexplored, which is the same consistency-models question the spoke keeps meeting. Hybrid logical clocks are used throughout the commit protocol and never defined here; that is the next thing to read, and it is the piece that decides whether "commit hybrid timestamp" means what Spanner's TrueTime means.

The algorithm, now sourced (added 2026-08-22). The per-tablet Raft groups this page describes are specified in raft-paper — strong leader, randomized election timeouts, joint consensus for membership change, and the five safety properties the design guarantees at all times.

Related

citus · postgresql · postgresql-extensions · consensus · paxos · podc-lecture-notes · part-time-parliament · database-sharding · cross-shard-queries · consistency-models · awesome-postgres · operational-databases