How Strata keeps every write, and what it does when regions can’t talk.

Strata runs every transaction at the SERIALIZABLE isolation level. There is no weaker level to opt into by accident: if two transactions could produce a result that no serial order would, one of them is aborted and retried.

Each transaction takes a timestamp from a hybrid logical clock: physical time from the node, plus a logical counter that moves forward whenever the node sees a later timestamp in a message. Clocks across regions are kept within 250 ms of each other. A node that drifts further stops serving and leaves the cluster on its own.

Reading at a timestamp

A read at timestamp t sees every write committed before t and nothing after it. When a read meets an uncommitted write inside its clock-uncertainty window, it waits for that write to resolve or restarts at a later timestamp. No client ever reads a value and then sees an older one.

In SQL

• BEGIN; … COMMIT; is serializable. READ COMMITTED and REPEATABLE READ are accepted for compatibility and run as SERIALIZABLE.
• Retry errors use SQLSTATE 40001, the code Postgres uses for serialization failures, so existing retry logic works unchanged.
• The TypeScript and Go clients retry 40001 for you with jittered backoff, up to five attempts.

Strata splits each table into ranges of about 256 MB by primary key. Every range has a replica in each of the six regions and one leader, placed in the region where most of its writes come from. For a table created WITH (strata.home = 'nearest'), that is the region nearest each row’s writer.

A write goes to the range leader. The leader appends it to its log and sends it to the other five replicas at once. When two of them have written the entry to disk and answered, three regions hold it: the leader commits and replies. The remaining replicas catch up in the background.

Why three

Three copies in three regions means any two regions can be lost without losing a committed write. The leader never waits for the slowest regions. It commits on the first two acknowledgements, which in practice come from its two nearest neighbours.

Every replica tracks a closed timestamp: a moment before which it has received every write its leader will ever commit. Leaders advance it every 200 ms and ship it with the log, so a healthy follower trails real time by about one round trip to its leader.

When a query allows staleness, as with SET strata.read_staleness = '2s', the planner picks a timestamp two seconds back and sends the read to the nearest replica whose closed timestamp has passed it. The answer is a consistent snapshot: every row is from the same moment, and nothing committed before that moment is missing.

Reads inside a read-write transaction, and reads that allow no staleness, go to the range leader. For rows homed near their writer, the leader is usually the nearest region anyway.

Leaders hold leases on their ranges. A lease is granted and renewed by four regions and lasts 900 ms. A region that stops answering heartbeats stops renewing, so within 900 ms every lease it held has expired, and nobody else can be granted one before that.

The surviving replicas then elect a new leader for each range. An election needs votes from four regions, and any four regions include at least one of the three that hold each committed write, because 3 + 4 is more than 6. The new leader copies the tail of the log from that region before it accepts writes. That is why no committed write is lost.

Clients see a closed connection, or error 40001 on a transaction in flight. The client library reconnects to the next nearest region and retries. A transaction that never got a commit reply is retried; one that did is already safe in three regions.

Three regions down

With three of six regions down, three remain. That is enough to hold a committed write, but not enough to grant a lease. Strata pauses writes rather than accept one it might not keep. Reads continue from local copies, and every response reports how stale it is. Bring one region back and writes resume.

A partition is not a failure. Both sides are running, and each believes the other is down. Strata handles it exactly as it handles a failure, with one rule that settles every case: a write lease needs four regions.

Split six regions four against two, and the side with four keeps its leases or wins them within 1.8 seconds. The side with two cannot renew; within 900 ms it stops accepting writes and keeps serving reads, each marked with how old it is.

Split three against three, and neither side has four. Writes pause everywhere until the network heals. It is the one case where a partition stops writes, and it is deliberate: the alternative is two sides accepting writes that cannot both be kept.

• 4 | 2: the four keep writing; the two serve reads marked stale.
• 5 | 1: the isolated region stops writing within 900 ms.
• 3 | 3: writes pause on both sides; reads continue.
• Healing: the cut-off side catches up from the log. There is nothing to merge.