Local-first vs cloud-first note apps: what breaks when you go offline

The Seven Principles of Local-First Software

In 2019, Martin Kleppmann and his colleagues at Ink & Switch published a seminal research paper titled "Local-first software: you own your data, in spite of the cloud." They articulated seven core ideals that redefine how human software should work in a world dominated by fragile cloud services:

1. No spinners: your work at your fingertips instantly without waiting for remote server round-trips.

2. Your work is not trapped on one device: multi-device synchronization is continuous and backgrounded.

3. The network is optional: every feature functions identically whether you are on fiber broadband, spotty cellular data, or completely disconnected in airplane mode.

4. Seamless collaboration with peers: multiple devices can write to the same documents simultaneously without locking files.

5. The long now: software and data structures that continue working for decades without relying on vendor server maintenance.

6. Security and privacy by default: client-side encryption protects your intellectual property from remote cloud breaches.

7. You retain ultimate ownership and control: files exist in open, inspectable formats on your local storage device.

What breaks in cloud-first architectures

Cloud-first applications (such as Notion, Coda, or Roam Research) are architected around a centralized client-server paradigm. The canonical copy of your workspace lives inside a remote cloud database (typically PostgreSQL or DynamoDB), while the desktop app is essentially an embedded browser window displaying a transient, cached view.

When network conditions degrade or connectivity drops, cloud-first architectures break down in three critical ways:

Latency Tax: Every keystroke, page navigation, or database query must validate against a remote API endpoint. Even on high-speed Wi-Fi, 100ms round trips create subtle micro-stutters that interrupt cognitive flow compared to memory-mapped local reads.

Fragile Offline Modes: Offline support in cloud-first apps is an afterthought bolted on via Service Workers or browser IndexedDB caches. If you close the window or experience an app crash before pending changes reach the cloud, offline edits can vanish permanently.

Destructive Conflicts: When two paired devices make simultaneous edits, cloud systems typically resolve conflicts using crude "Last-Write-Wins" timestamps at the document level. This silently wipes out entire paragraphs written on the second device without warning.

• Latency Tax: Every keystroke, page navigation, or database query must validate against a remote API. Even on fast Wi-Fi, 100ms round trips feel sluggish compared to local memory.
• Fragile Offline Modes: Offline support in cloud-first apps is an afterthought bolted on via Service Workers or IndexedDB caches. If you close the app before syncing, pending edits can be lost forever.
• Destructive Conflicts: When two devices edit simultaneously, cloud apps use "Last-Write-Wins" timestamps at the document level, silently wiping out whole paragraphs written on the second device.

How local-first solves conflict-free sync with CRDTs

Local-first software completely flips the architectural hierarchy: your local filesystem and SQLite database are the definitive, authoritative source of truth. Writes are instantaneous (0ms perceived latency) because they commit immediately to local disk. The network functions purely as a secondary, background transport mechanism.

To merge edits across devices without data loss or modal merge conflict dialogs, local-first applications utilize Conflict-free Replicated Data Types (CRDTs) like Yjs. CRDTs represent document edits as mathematical operations that can be applied in any chronological order across multiple machines, converging deterministically to the identical document state.

Whether you take notes on your laptop during an offline flight or edit tasks on your desktop at home, the sync engine reconciles every character change automatically the second both devices re-establish connectivity.

Cloud-First (Last-Write-Wins):
Device A edits paragraph 1 at 10:00:01
Device B edits paragraph 2 at 10:00:02
Result: Server overwrites Device A's paragraph entirely.

Local-First (Yjs CRDT):
Device A inserts char block [A1..A15] at offset 0
Device B inserts char block [B1..B20] at offset 42
Result: Both operations merge deterministically. Zero data lost.

Instant search: SQLite FTS5 vs Cloud API search

When your personal knowledge base is stored locally in an embedded SQLite database, full-text search across 50,000 notes executes in 4 to 8 milliseconds using SQLite’s native FTS5 engine and BM25 ranking.

You get instant, interactive search results as you type every single letter, with zero network latency, zero bandwidth consumption, and complete resilience against server outages or API rate limits.