Skip to content

SYSTEM Cited by 1 source

cr-sqlite (CRDT SQLite extension)

What it is

cr-sqlite is an open-source SQLite extension from vlcn-io that turns specified SQLite tables into CRDT-managed tables. Writes to CRDT tables are logged in a crsql_changes table; replicas merge those changes deterministically under last-write-wins with logical timestamps (causal ordering, not wall-clock).

CRDT mechanics documentation: doc/crdts.md (forked copy inside the Corrosion repo).

How it plugs into Corrosion

Fly.io's Corrosion uses cr-sqlite as the conflict-resolution layer. As application rows are updated in ordinary SQL tables, cr-sqlite collects the resulting changes from crsql_changes; Corrosion bundles them into update packets and gossips them over the cluster. Every node eventually receives the same set of updates in some order, and every node converges to the same "working set" picture.

Key integration properties disclosed in sources/2025-10-22-flyio-corrosion:

  • Row-level merge, LWW on logical timestamps — not wall-clock, so no dependency on NTP synchronisation.
  • Per-column change tracking — changes to any column are logged, enabling fine-grained merge.
  • Transparent to consumers — applications open the local SQLite with the standard client and see a normal table; cr-sqlite is invisible in the read path.

Operational hazards

cr-sqlite's design produces specific operational traps when deployed at Corrosion-scale:

  • Nullable-column backfill amplification — adding a nullable column to a large CRDT table makes cr-sqlite backfill every row at once, triggering a fleet-wide reconciliation storm. See concepts/nullable-column-backfill-amplification.
  • Schema migration is a hazard surface — DDL changes need careful staging; there's no silver-bullet playbook yet.
  • No unique constraints, no referential integrity — the CRDT model can't enforce global invariants by design.

Seen in

Last updated · 200 distilled / 1,178 read