How OPFS and WASM SQLite are powering the local-first web revolution

If you’ve been paying attention to the engineering chatter around the Bay Area lately, you’ve probably heard the breathless hype about the "local-first" web revolution. The narrative is incredibly seductive: we are moving away from thin-client architectures and returning to fat-client models, powered by the convergence of WebAssembly (WASM) and the Origin Private File System (OPFS).

The pitch is that we can finally eliminate network loading states, drastically reduce our cloud infrastructure costs, and give web applications the snappy, zero-latency feel of native desktop software. But before we all rush to rewrite our frontends and push our compute to the edge, we need to take a step back and look at what we are actually signing up for.

The mechanics of the new local-first stack

Historically, running a relational database in the browser was an exercise in frustration. We were constantly bottlenecked by the impedance mismatch between synchronous database I/O and the browser’s asynchronous storage APIs, like IndexedDB.

That changed when the core SQLite team released version 3.40.0, introducing an official WebAssembly build with a dedicated OPFS Virtual File System. This wasn't just another experimental hack; it legitimized the movement. Coupled with the W3C Web Platform Incubator Community Group (WICG) stabilizing the FileSystemSyncAccessHandle API across Blink, Gecko, and WebKit, OPFS has become a universal standard. We now have highly performant, synchronous read and write access directly to the local disk from Web Workers.

You can compile SQLite to WASM, map its virtual file system to OPFS, and execute SQL queries in sub-milliseconds. It sounds like a frontend developer's dream. But when you look past the impressive benchmarks, the practical reality of maintaining this architecture is far less glamorous.

The illusion of permanent storage

The most glaring issue with relying on OPFS for local-first architecture is that browser storage is inherently volatile. Despite its capabilities, OPFS remains subject to strict browser storage quotas and Least Recently Used (LRU) eviction policies.

If a user's device runs low on disk space, the operating system will pressure the browser to clean house. The browser, in turn, will ruthlessly evict local data. To mitigate this data loss, we are told to actively utilize the navigator.storage.persist() API to request persistent storage rights.

Think about the user experience here. We are forcing users to navigate intimidating browser permission prompts just to ensure the app they are using doesn't spontaneously delete their unsynced work. It introduces a massive point of friction and highlights a critical technical constraint that the "zero-latency" evangelists tend to gloss over.

Trading cloud costs for client-side complexity

The local-first model theoretically simplifies developer ergonomics by replacing complex state management libraries with standard SQL. But in practice, we aren't eliminating complexity; we are just moving it from the backend to the client.

To make local-first work, you need robust synchronization. We are seeing the emergence of specialized sync layers like PowerSync and ElectricSQL, which maintain active-active replication between local WASM-SQLite instances and remote PostgreSQL databases. These tools use logical replication to stream database subsets to the client, handling complex delta-syncing. Furthermore, the ecosystem is heavily leaning into Conflict-Free Replicated Data Types (CRDTs) built as loadable SQLite extensions, like the cr-sqlite project, to handle offline modifications and eventual merging.

This is a phenomenal feat of engineering, but we have to ask: who actually needs this level of complexity? You are now shipping a database engine, a synchronization protocol, and complex CRDT logic directly to the user's browser. This introduces significant initial cold-start load times, completely negating the performance benefits for first-time visitors.

Unresolved hurdles and the reality of the web

Beyond the heavy initial payload, we still have to navigate cross-tab locking constraints—a notoriously difficult problem when multiple browser tabs are trying to synchronously access the same local database file. Then there are the security implications of client-side data storage. Pushing substantial subsets of your database to a user's local disk vastly increases the surface area for data exfiltration and tampering.

Optimistic UI design is fantastic when it works, but when conflicts inevitably arise or sync protocols fail, the user is left with a fragmented experience.

There is undoubtedly a place for OPFS and WASM SQLite. If you are building a highly complex, interaction-heavy enterprise tool—think a collaborative design application like Figma, or a specialized offline-first field data collection tool—this stack might genuinely be a holy grail moment.

But for the vast majority of web applications, this architecture is massive overkill. We shouldn't adopt an incredibly complex fat-client model just because the technology is finally mature enough to support it. Sometimes, a quick network request to a well-optimized server is exactly what the user actually needs.