Logical DML replication
Replication is logical, not physical page shipping. The heap follows row-level puts and deletes, and the lake follows agreed version numbers.
Consensus
Writes commit through quorum
Database nodes join a Raft group where the leader accepts writes and group-commits under one fsync per quorum ack. A three-node group keeps the data on all three, followers apply committed entries through the same operator path the leader used, and follower reads take a ReadIndex round trip so they stay linearizable.
Completezyron-raftConsensus and replication ship in the engine today.
Commit path
How a write commits
A client sends a write to the leader. The leader appends it to the raft log and replicates the entry to both followers. Once a quorum has acknowledged the append, the leader group-commits and answers the client. Concurrent transactions share that sync, so the group pays one fsync per quorum ack rather than one per transaction, the same batching the single-node write-ahead log uses.
The write is durable once a quorum has the entry, not once every node does. The leader batches concurrent commits into one fsync per quorum ack, so throughput rises with concurrency instead of paying a sync per transaction.
Replication flow
One write, followed end to end
The commit path above shows the fan-out. This is the same write followed from the moment it is sealed on a grouped node to the moment a follower answers a read that depends on it, including where the change feed lands so a consumer sees the same record on every member.
01
Seal the changeset
A write on a grouped node is sealed into a changeset. Savepoints are resolved here, at capture time, so rows a savepoint rolled back are never part of it.
02
Propose to the Raft log
The sealed changeset is proposed to the Raft log as a single entry.
03
Pipeline to every follower
The leader pipelines the entry to every follower in the group as AppendEntries.
04
One fsync per member
Each member fsyncs the entry once. Concurrent transactions share that sync, which is the group commit on the commit path above.
05
Answer after quorum
Once a quorum has acknowledged, the leader answers the client. The write is on a majority before the client hears about it.
06
Apply on every member
Every member runs the same applier over the committed entry, so a follower's rows come from the same code path that produced the leader's.
07
Write the feed at the raft index
Every member writes the change feed at the raft index so a consumed position names the same record on every member.
08
Read on a follower
A read on a follower takes a ReadIndex round trip to the leader, then waits for local apply to reach that index before answering.
A change stream consumer reads that feed and advances its position inside its own transaction, covered on the change streams page. What a follower read has to do to stay linearizable is under Reads below.
Coverage
Everything replicates
Replication is not a subset of SQL that happens to work. Every DML shape, DDL, explicit BEGIN blocks, savepoints, MERGE, CALL, DO, and prepared statements over the extended protocol all ride the same channel.
One channel, every statement shape
There is no second code path for the interesting cases. A prepared statement bound over the extended protocol replicates the same way a plain INSERT does, and a multi-statement BEGIN block replicates as the transaction it is. An exhaustive classifier covers every statement in the grammar, and a conformance suite runs each one against a live three-node group over the wire.
INSERTUPDATEDELETEMERGECALLDOBEGINSAVEPOINTDDLExtended protocol
No primary key required
A table without a primary key still replicates. The applier falls back to a secondary index probe, or to a full-image match following REPLICA IDENTITY FULL semantics.
Savepoints resolved at capture time
A savepoint rollback is settled while the change is captured, so rows that were rolled back never ship to a follower in the first place.
DDL keeps the real command tag
DDL runs on the connection, so the client sees the command tag the statement actually produced. If the client drops mid-statement, the applier picks it up.
Cluster settings ride the log
A cluster setting travels the consensus log like any other entry, behind a cluster version gate that waits for the lowest member version. A rolling upgrade never applies a setting a member cannot read.
A version stamped in every frame
The client, mesh, and consensus wire protocols are each registered with an add-only rule, and every frame carries its protocol version, so mixed versions on the wire are expected rather than surprising.
Lake tables replicate by agreed version number rather than by row, which fits the way ZyronLake commits a new version per change.
Reads
Linearizable reads, from any node
A follower read that can return stale data is a different database from the one the client thinks it is talking to. Follower reads in a group go through ReadIndex, so spreading reads across the group does not weaken what a read means.
ReadIndex round trip
A follower read takes a ReadIndex round trip to the leader before it answers, so the read cannot return a state older than a write that has already been acknowledged.
The same operator path
Followers do not run a separate apply engine. Committed entries go through the same operator path the leader used, so a follower's rows are produced by the same code.
Any node serves reads
Reads are not pinned to the leader. Any node in the group can answer them, which keeps the mesh property that any client can hit any node.
A Raft group sits inside the wider mesh, where nodes peer over the wire and a single query reaches across them.
Durability
Durability and recovery
Joining a group changes what durability means on a node. The local log and the agreed log have to end up telling the same story, and only one of them is allowed to decide that a row is committed.
The raft log is a storage tier
Backing
Group-committed on the leader, quorum-replicated to followers, byte-aware residency cap with older entries paged from disk.
Purpose
The consensus record of DML and DDL, used for replication and for failover.
The WAL commit record carries the raft index
Local durability and the agreed log are reconciled at recovery instead of guessed at. The commit record on disk names the raft index it belongs to, so a restarted node knows exactly where it stands against the group.
Background writers stand down
Inside a group, the background writers that would otherwise commit data locally stand down. Only the replicated log commits data, so there is one path to a durable row.
Byte-aware log residency cap
The raft log holds a bounded number of bytes in memory rather than a fixed entry count. Older entries page in from disk on demand when a follower needs them.
Whole-cluster snapshots
A snapshot covers the whole cluster, and its byte-aware compaction is bounded by the slowest group member, so a lagging node is never compacted out from under.
Membership
One group per cluster, four roles
A cluster runs one Raft group. Nodes take a role in it, and changing who is in the group is a single command.
Leader
Accepts writes, appends to the raft log, and group-commits under one fsync per quorum ack.
Follower
Applies committed entries through the same operator path the leader used, and serves reads through ReadIndex.
Learner
Catches up on the log without voting, then gets promoted into the group once it is current.
Single-command membership change
Adding or removing a member is one command against the group, not a multi-step reconfiguration dance.
The group is also what a rolling upgrade runs over. New binaries land across the group with drain coordination and per-node rollback, covered on the upgrades page.
Numbers
The numbers
Measured on a three-node group with the leader accepting writes and reads served through ReadIndex. Failover time, append cost, snapshot cost, and how far behind a follower actually falls.
~216ms
Leader election after a kill
~0.19µs
Single log append
~1.13s
Snapshot 1GB, create
~2.72s
Snapshot 1GB, transfer
~99.8%
Follower keep-up vs leader
~97entries
Worst follower lag
Where the rest of it lives
Throughput and hot-path latency charts for consensus and replication, plus every other subsystem, are on the performance page. The mesh page covers the wider federation story, where nodes peer over the wire and a single query reaches across them.
Running in the next five minutes
Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.