Sync Engine

Middleware that keeps a local copy of data on the device and reconciles changes with the server in both directions.

A sync engine is the layer that makes local-first software work: the application reads and writes against a local database (usually SQLite), and the engine quietly pushes local mutations up, pulls server changes down, and reconciles conflicts so that every device converges. The user interface stops waiting on the network because reads are local; sync happens in the background.

Why it matters to an indie builder: offline support and multi-device continuity are premium features users notice, and they used to cost months of bespoke state-transfer code. Sync engines turned the pattern into infrastructure: PowerSync, Jazz, Instant and ElectricSQL-style products handle the hard parts, change tracking, tombstones, conflict policy, reconnection, so a solo builder can ship what used to require a platform team.

A concrete example: a field-notes app. A technician edits in a basement with no signal: writes land in local SQLite and the screen updates instantly because there is no round trip. Two hours later the connection returns; the engine pushes the five queued mutations, pulls a colleague's changes, and applies a conflict policy, per-field last-writer-wins for form data, CRDT merging for shared text. The user never saw a spinner or a retry button.

Common mistakes: trusting the client (the server must re-validate every mutation: auth, permissions, business rules, because the device is in hostile hands), hand-waving deletions (engines need tombstones or deleted rows resurrect on the next sync, a classic bug), picking a conflict policy without thinking about the data (last-write-wins is fine for a profile field and wrong for collaborative documents), and building your own diffing before you have felt the edge cases; use an engine, the edge cases are the product. The local-first blocks on IndieBoot track this fast-moving corner of the stack.