Multi-master sync lives or dies on one question: when two sides disagree, does anything disappear? The GF Cloud DB's answer is structural — every conflict keeps the loser, recoverable — and the benchmark proves it under conflicts, kills, and chaos.
Multi-master is where most data layers quietly give up — the moment two copies both accept writes, conflicts, ordering, and recovery become your problem. That's exactly the gap the GF Cloud DB closes: two live databases, both writable, converging to identical tables — with conflict resolution that never discards data silently.
The six scenarios below are the correctness category of the GF Cloud DB Benchmark. All of them pass — 152/152 scenario checks as of 2026-07-03.
Two live databases, both accepting writes, edit the same row while disconnected. On sync, the conflict resolves deterministically — production wins — and the losing version is preserved and restored live in the test. No silent overwrite, no last-writer roulette.
Verified live: the losing write recovered after the conflict
The chaos suite kills the sync process in the middle of a transfer. The entire in-flight direction rolls back atomically — no half-applied state. Recovery is just running it again: the re-run is idempotent and completes cleanly.
Atomic rollback + idempotent re-run, every kill point tested
One side accumulates 500 changes, the other 200, before they reconnect. The catch-up produces exactly 40 conflicts — the number the scenario predicts — and every single one is recoverable. Deletes propagate in both directions without resurrecting rows.
500 + 200 offline changes · exactly 40 conflicts · all recoverable
A fuzzer runs 1,500 random inserts, updates, and deletes across both nodes with syncs interleaved at random. At the end, both databases are compared table by table. They match — full parity, every run.
1,500-op fuzz → full-table parity
2,000 writes across 4 concurrent threads while 7 syncs run in parallel — finished in 4.1 seconds with zero lost rows, zero duplicates, and every write accounted for. Sync never asks your app to pause.
4 writers ∥ 7 syncs · 4.1s · zero lost, zero duplicated
A v2 database syncs against a v1 database mid-rollout. Nothing breaks — the sync stays tolerant of the mismatch and both sides converge fully once the migration lands. Real deployments never upgrade everything at once; the benchmark doesn't either.
v2 ↔ v1 stays tolerant · converges after migration
The other half is efficiency — sync that ships kilobytes, not your database.
