Why Local-First Software Is the Future and its Limitations | RxDB

Imagine a web app that behaves seamlessly even with zero internet access, provides sub-millisecond response times, and keeps most of the user's data on their device. This is the local-first or offline-first approach. Although it has been around for a while, local-first has recently become more practical because of maturing browser storage APIs and new frameworks that simplify data synchronization. By allowing data to live on the client and only syncing with a server or other peers when needed, local-first apps can deliver a user experience that is fast, resilient, and privacy-friendly.
However, local-first is no silver bullet. It introduces tricky distributed-data challenges like conflict resolution and schema migrations on client devices. In this article, we'll dive deep into what local-first means, why it's trending, its pros and cons, and how to implement it in real applications. We'll also discuss other tools, criticisms, backend considerations, and how local-first compares to traditional cloud-centric approaches.
In local-first software, the primary copy of your data lives on the client rather than a remote server. Rather than sending each read or write over the network, you store and manipulate data in a local database on the user’s device. Sync then happens in the background, ensuring all devices eventually converge to a consistent state.
This approach is increasingly popular because it leads to instant app responses (no network delay for most operations), genuine offline capability, and more direct data ownership for users. Local-first apps also sidestep outages and if the server or internet goes down, users can keep working with their local data. When connectivity returns, everything syncs. This makes the user experience more resilient and gives them control of their data, which is especially appealing when privacy concerns or limited connectivity are key factors.
Local-First software: A set of principles for software that enables both collaboration and ownership for users. Local-first ideals include the ability to work offline and collaborate across multiple devices, while also improving the security, privacy, long-term preservation, and user control of data.
The push for local-first is driven by a few key new technological capabilities that previously restricted client devices from running heavy local-first computing:
Relaxed Browser Storage Limits: In the past, true local-first web apps were not very feasible due to storage limitations in browsers. Early web storage options like cookies or localStorage had tiny limits (~5-10MB) and were unsuitable for complex data. Even IndexedDB, the structured client storage introduced over a decade ago, had restrictive quotas on many browsers: For example, older Firefox versions would prompt the user if more than 50MB was being stored. Mobile browsers often capped IndexedDB to 5MB without user permission. Such limits made it impractical to cache large application datasets on the client. However, modern browsers have dramatically increased these limits. Today, IndexedDB can typically store hundreds of megabytes to multiple gigabytes of data, depending on device capacity. Chrome allows up to ~80% of free disk space per origin (tens of GB on a desktop), Firefox now supports on the order of gigabytes per site (10% of disk size), and even Safari (historically strict) permits around 1GB per origin on iOS. In short, the storage quotas of 5-50MB are a thing of the past and modern web apps can cache very large datasets locally without hitting a ceiling. This shift in storage capabilities has unlocked new possibilities for local-first web apps that simply weren't viable a few years ago.
New Storage APIs (OPFS): The new Browser API Origin Private File System (OPFS), part of the File System Access API, enables near-native file I/O from within a browser. It allows web apps to manage file handles securely and perform fast, synchronous reads/writes in Web Workers. This is a huge deal for local-first computing because it makes it feasible to embed robust database engines directly in the browser, persisting data to real files on a virtual filesystem. With OPFS, you can avoid some of the performance overhead that comes with IndexedDB-based workarounds, providing a near-native speed experience for file-structured data.
WebAssembly: Another advancement is WebAssembly (WASM), which allows developers to compile low-level languages (C, C++, Rust) for execution in the browser at near-native speed. This means database engines, search algorithms, vector databases, and other performance-heavy tasks can run right on the client. However, a key limitation is that WASM cannot directly access persistent storage APIs in the browser. Instead, all data must be sent from WASM to JavaScript (or the main thread) and then go through something like IndexedDB or OPFS. This extra indirection is slower compared to plain JavaScript->storage calls, which is one of the tradeoffs when you compare RxDB with SQLite-Wasm and PGlite. Looking ahead, there might come up future APIs that allow WASM to interface with persistent storage directly, and if those land, local-first systems could see another major boost in performance.
Improvements in Local-First Tooling: A major factor fueling the rise of local-first architectures is the dramatic leap in client-side tooling and performance. For instance, consider a local-first email client that stores one million messages. In 2014, searching through that many documents, especially with something like early PouchDB, could take minutes in a browser. Today, with advanced offline databases like RxDB, you can use the OPFS storage with sharding across multiple web workers (one per CPU) and use memory-mapped techniques. The result is a regex search of one million of these email documents in around 120 milliseconds - all in JavaScript, running inside a standard web browser, on a mobile phone.
Better yet, this performance ceiling is likely to keep rising. Ne