Local-first software keeps the primary copy of user data on their own devices, enabling offline use, instant interactions, and long-term data ownership. This report surveys the state of the local-first ecosystem in early 2026, covering the maturation of CRDTs, the rise of SQLite-based sync engines, emerging frameworks, platform-level adoption, and practical architecture patterns for building local-first applications today.
The term "local-first" was introduced by Kleppmann et al. in their 2019 Ink & Switch essay, describing software that prioritizes local data storage and peer-to-peer sync over cloud-centric architectures. Seven years later, the ideas have moved from academic curiosity to production reality.
Several converging trends have driven adoption: growing user concern over data ownership, the maturation of conflict-free replicated data types (CRDTs), first-party platform support from Apple and Google, and a new generation of sync engines that treat SQLite as the universal application database.
This report examines five areas: CRDT maturation, SQLite sync engines, the Zero framework, platform-level primitives, and architecture patterns for practitioners.
Conflict-free replicated data types allow multiple users (or devices) to edit shared data concurrently and merge changes automatically, without a central server to coordinate. In 2026, two implementations dominate the ecosystem.
Automerge, originally developed at Ink & Switch, reached version 3.0 in late 2025. The release introduced a columnar storage format that reduced document sizes by 40-60% compared to Automerge 2.x, and a new sync protocol that achieves sub-millisecond merge times for typical document sizes.
Key improvements in 3.0:
Automerge's strongest use case remains rich-text collaboration and complex nested documents. Its JSON-like data model maps naturally to application state.
Yjs continues to be the most widely deployed CRDT library, powering collaborative editing in tools like Notion, Tiptap, and BlockNote. The ecosystem around Yjs has grown substantially:
Yjs's relative encoding strategy remains memory-efficient for real-time collaboration, though it trades off some of Automerge's richer data model capabilities.
| Criteria | Automerge 3.0 | Yjs |
|---|---|---|
| Data model | JSON-like, nested maps/lists | Shared types (Map, Array, Text, XML) |
| Best for | Complex documents, offline-heavy | Real-time collaboration, text editing |
| Storage efficiency | Excellent (columnar format) | Good (relative encoding) |
| Ecosystem | Growing | Mature, large |
| Language support | Rust, JS, Swift, Kotlin | JS (primary), Rust port |
Perhaps the most significant shift in local-first architecture is the convergence on SQLite as the application database, paired with sync engines that replicate changes between SQLite instances.
cr-sqlite, created by Matt Wonlaw, adds CRDT semantics to SQLite tables via a loadable extension. It uses column-level last-write-wins by default, with optional CRDT types for counters and sets. The approach is pragmatic: developers use normal SQL, and cr-sqlite handles conflict resolution transparently.
-- Enable CRDT tracking on a table
SELECT crsql_as_crr('todos');
-- Normal SQL operations work as expected
INSERT INTO todos (id, title, done) VALUES (?, ?, ?);
UPDATE todos SET done = 1 WHERE id = ?;
-- Sync changes between databases
SELECT * FROM crsql_changes WHERE db_version > ?;cr-sqlite's small footprint makes it suitable for embedded and mobile applications where a full sync engine would be excessive.
PowerSync provides a managed sync layer between a backend Postgres (or MongoDB) database and client-side SQLite. It uses a "sync rules" configuration to define which data syncs to which clients, supporting row-level security and partial replication.
The architecture is straightforward: PowerSync watches the backend database's change stream, filters changes through sync rules, and pushes them to clients via a custom protocol. Clients operate on a local SQLite database and write changes back through a developer-defined upload endpoint.
ElectricSQL has evolved significantly, pivoting from its initial CRDT-based approach to a simpler "sync engine" model. The current version (v0.9) provides bidirectional sync between Postgres and client-side SQLite with a shape-based API:
import { useShape } from '@electric-sql/react';
const { data: todos } = useShape({
url: 'http://localhost:3000/v1/shape',
params: { table: 'todos', where: 'user_id = ?' }
});ElectricSQL's shape subscriptions allow clients to sync subsets of data efficiently, making it practical for applications with large datasets.
Zero, developed by Rocicorp (the team behind Replicache), represents a new approach to local-first architecture. Rather than syncing at the database level, Zero provides a reactive query layer that keeps a local cache synchronized with a server.
Zero's architecture consists of three components:
The key insight is that Zero doesn't replicate tables -- it replicates query results. This means clients only store the data they actually need, and the server can efficiently determine which clients need which updates.
By early 2026, Zero has seen adoption in enterprise applications where its combination of real-time sync, offline support, and fine-grained permissions fits well. The framework's approach to authorization -- running permission checks on the server while allowing optimistic client-side writes -- addresses a pain point that pure CRDT approaches struggle with.
"The hardest problem in local-first isn't sync -- it's authorization. Zero solves this by keeping the permission model server-side while keeping the data local." -- Aaron Boodman, Rocicorp
At WWDC 2025, Apple announced CRDT primitives for CloudKit, allowing developers to use CKCRDTRecord types that merge automatically across devices. The initial release supports:
This is significant because it brings CRDT concepts to the millions of developers building on Apple's platforms, even if the initial CRDT type support is limited compared to Automerge or Yjs.
Google has taken a different approach, investing in Room (Android's SQLite abstraction) with improved offline-first patterns and providing better tooling for sync via Firebase Extensions. While not CRDT-based, the direction signals platform-level recognition that offline-first is a baseline expectation.
For practitioners building local-first applications in 2026, several patterns have emerged as best practices.
The dominant architecture puts SQLite at the center of the client application. All reads come from the local database. All writes go to the local database first, then sync to the server asynchronously.
User Action
-> Write to local SQLite
-> UI updates instantly (reactive query)
-> Sync engine pushes change to server
-> Server validates, persists, broadcasts
-> Other clients receive and applyThis pattern gives instant UI response times and full offline capability. The sync engine handles conflict resolution, retries, and partial connectivity.
The right conflict resolution strategy depends on the data type:
Most applications use a mix: LWW for most fields, CRDTs for collaborative content, and server authority for business-critical operations.
Schema evolution is a particular challenge for local-first applications since you can't just run a migration on every client simultaneously. The emerging consensus is:
Despite the progress, several challenges remain unsolved or under-addressed:
Local-first software has transitioned from a research ideal to a practical architecture. The convergence of mature CRDTs (Automerge 3.0, Yjs), SQLite-based sync engines (cr-sqlite, PowerSync, ElectricSQL), purpose-built frameworks (Zero), and platform-level support (Apple CloudKit CRDTs) means that developers in 2026 have viable, production-ready options.
The key insight from the current landscape is that there is no single "right" approach. The best architecture depends on data shape, collaboration needs, consistency requirements, and target platforms. What has changed is that all of these approaches are now mature enough to build on with confidence.