Last October I was in a hotel room in Lisbon, the night before I was supposed to demo a project management tool my team had spent four months building. The hotel Wi-Fi was doing that thing where it connects but nothing actually loads. I watched our app, a piece of engineering I was genuinely proud of, render a blank screen with a spinner, then a timeout error, then nothing.
I pulled out my phone, tethered to cellular, and got a shaky connection. Every click was a two-second wait. Move a task? Spinner. All that infrastructure (React, Node, Postgres, Redis) and the thing couldn’t show me my own data without a round-trip to a server 3,000 miles away. That was the night I stopped treating local-first architecture as academic research and started seeing it as a survival requirement.
Local-first is not just offline-first
I keep having this conversation at meetups, so let me clear it up. Local-first architecture is not just adding a service worker. Offline-first usually means your app handles network loss gracefully, but the server stays the source of truth: when the network comes back, the server wins. That is a performance optimization, not a data architecture.
In a true local-first setup, the user’s device holds the primary copy of their data. The app reads and writes to a local database instantly, and syncing happens in the background. The server, when it exists, is a sync peer, not a gatekeeper. As I’ve argued before, when I tell teams to fix your data architecture rather than scale servers, the bottleneck is usually the round-trip, not the processing power.
The client is not a thin view requesting permission to show data. The client is a node in a distributed system with its own database.
When you should (and should not) do this
Local-first is a bad fit when your data is mostly server-generated. Analytics dashboards, social feeds, and search results are better off consuming a traditional API. It is also wrong for systems that need strong transactional consistency, like banking or inventory, where eventual consistency will lose you money.
But for note-taking, document editing, collaborative design, or field apps on flaky connections, it is worth the trouble. The point is user-generated data that has to survive the server going down.
The 2026 stack: SQLite in the browser
Forget localStorage. It is synchronous and caps out around 10MB. What people are actually using now is SQLite running in the browser through WebAssembly (WASM), persisted to the Origin Private File System (OPFS). That gives you a real relational database, with SQL, transactions, and indexes, inside the browser sandbox.
Roughly what a production init looks like with wa-sqlite. Note the WAL mode: it is critical for handling concurrent writes in modern browsers.
async function bbioon_initLocalDB() {
const module = await SQLiteAPI.initialize();
const vfs = new OPFSCoopSyncVFS('project-db');
await vfs.initialize(module);
const db = await module.open_v2('workspace.db');
// PRAGMA journal_mode=WAL is a must for performance
await module.exec(db, `PRAGMA journal_mode=WAL`);
await module.exec(db, `CREATE TABLE IF NOT EXISTS tasks (
id TEXT PRIMARY KEY,
title TEXT NOT NULL,
status TEXT DEFAULT 'backlog',
updated_at TEXT DEFAULT (datetime('now'))
)`);
return db;
}Handling conflict resolution without the headaches
The part that scares most developers is conflict resolution. If two users edit the same task offline and then sync, who wins? My first attempt was naive: I let the remote server overwrite everything. Do not do that. Users hate losing data they spent an hour typing.
For most structured data, Last-Write-Wins (LWW) at the field level works fine. If User A changes the title and User B changes the due date, you keep both. You only need complex CRDTs (Conflict-Free Replicated Data Types) for high-stakes collaborative text editing like Google Docs.
If you are managing complex state transitions, keep your JavaScript module system architecture modular enough to swap sync engines. I have moved from custom sync to PowerSync and ElectricSQL, and that abstraction layer saved me weeks of refactoring.
Performance: the instant metric
In a local-first setup, reads are instant, under 2ms for a 500-row query on a MacBook, with no network and no spinner. Writes are instant too, because they hit the local SQLite file first. You pay for it during the initial sync, since bootstrapping a 5,000-task workspace might take 4 seconds on a slow 3G connection, but after that the UI never waits for the internet again.
If this local-first work is eating up your dev hours, I can take it on. I have been wrestling with WordPress and complex data sync since the 4.x days.
The final verdict
The best architecture is the one your team can debug at 2 AM. Local-first adds real complexity: migrations across a thousand different devices, sync boundaries, conflict flagging. But for the right app, it is the difference between a tool people tolerate and one that feels like an extension of their brain. Start small. Pick one feature, add a local database, and see how it changes the way the app feels.
