Uncategorized

Local-First Software: Why Engineers Move Data Off Cloud

Local-first software architecture diagram showing device-to-cloud data flow
Local-first software keeps data on-device with background cloud sync

At QCon London in March 2026, Martin Kleppmann opened his keynote with data showing AWS, Azure, and Google Cloud hold roughly 70% of the European market. The largest European cloud providers sit at about 2%. Two weeks earlier, Iran attacked three AWS data centers in the UAE with drones, severely damaging at least one. The region was still showing disrupted services on the AWS dashboard as Kleppmann delivered his talk. His proposed fix: local-first software. Meanwhile, Local-First Conf 2026 expects 350 attendees in Berlin this July, and FOSDEM 2026 added a dedicated track for local-first development. The movement is shifting from academic research to production adoption, and cloud-only SaaS is starting to look like the risky bet.

What Local-First Actually Means

Local-first is a software design philosophy where the user’s device is the primary home for data—sync is secondary, not foundational. All reads and writes hit a local database first, then asynchronous replication protocols sync changes to backend servers in the background. The result: 1000x faster interactions compared to server round-trips.

Kleppmann and colleagues defined seven ideals in their 2019 essay: Fast (no network latency), Offline (full functionality without connection), Multi-device (auto-sync when online), Collaboration (real-time or async), Longevity (works in 10 years even if vendor is gone), Privacy (data doesn’t have to leave device), and User control (you own your data, can export it, move it). Reading from local SSDs is thousands of times faster than waiting for server responses. Every interaction provides instant UI feedback. No loading spinners.

Why Cloud-Only Is Losing Ground

Three pressures converge: geopolitical risk, cost, and developer experience. Kleppmann’s sovereignty argument hits hardest. Europe depends on US cloud providers for 70% of its infrastructure, yet Microsoft has stated it would comply with US legal requests for EU citizen data stored in the EU, regardless of EU law. That’s vendor lock-in with geopolitical consequences. The AWS UAE attack validates the concern—centralized cloud infrastructure is a single point of failure, and it gets attacked.

Cloud cost is the second driver. ByteIota has covered this extensively: wasted cloud spend hit 29% in 2026, the first increase in five years. Local-first reduces hosting costs by requiring much less server-side compute. When your app works primarily off local data with background sync, you’re not paying for constant database queries and API round-trips. The cloud bill shrinks.

Developer experience is the third factor. Moreover, developers hate loading spinners. They hate unreliable network conditions breaking user workflows. Local-first eliminates both. Interactions mutate local state first, providing instant feedback. Synchronization happens in the background. Users don’t wait. That’s the UX win that drives adoption.

The Tech Stack: CRDTs, Sync Engines, Local Databases

The 2026 local-first tech stack is maturing. CRDTs—Conflict-free Replicated Data Types—enable multi-user collaboration without requiring a server to arbitrate. Multiple users edit the same data independently, and changes merge automatically without conflicts. Yjs is the high-performance option: memory-efficient, binary-based, scales for large documents. Automerge is the developer-friendly choice: JSON data model, Rust implementation with JavaScript bindings via WebAssembly.

Here’s the key insight most developers miss: you probably don’t need a CRDT. Only add a CRDT library if you have an actual collaborative editing requirement. Most offline-first apps just need queued writes that sync—a much simpler problem. PowerSync and ElectricSQL handle database replication without CRDT complexity. For local storage, PGlite (Postgres in WASM), RxDB (reactive database with CRDT plugin), and SQLite cover most use cases.

The ecosystem is young but growing fast. RxDB compares local-first development in 2024 to React in 2013: early stage, maturing tooling, limited engineers with production experience. That’s changing. The libraries work. The patterns are stabilizing. The conferences are filling up.

When to Choose Local-First vs Cloud-First

Local-first isn’t a silver bullet. It excels when speed, offline functionality, or privacy matter: field operations in low-connectivity environments, collaborative document editing, chat apps, note-taking and productivity tools, CRM systems for active leads and daily tasks. Cloud-first wins when you need centralized authority (banking, inventory management), enterprise security at scale (billions invested by cloud providers), or multi-tenant SaaS with shared infrastructure.

The pragmatic production pattern is hybrid-first: keep hot data local, store archives in the cloud. A CRM might keep Active Leads and Daily Tasks in a local sync engine while archiving historical records centrally. Not pure local-first, but local-first for the core user experience.

Limitations are real. Safari wipes IndexedDB data if users haven’t visited the site in seven days. Other browsers have their own eviction policies. Users can clear storage intentionally or accidentally. Local data cannot be 100% trusted to stay forever. Authentication and authorization add complexity—local-first systems work great until you need user access controls, which you almost always do. Storage and compute limits hit at scale: terabytes of photos require cloud storage and GPUs for inference. The ecosystem is still immature compared to cloud-first tooling.

Where This Is Heading

More than 70% of enterprises now operate in hybrid or multi-cloud environments, expected to reach 90% by 2027. Local-first isn’t replacing cloud—it’s shifting the default from “cloud-first, local-optional” to “local-first, cloud-optional.” Companies in logistics, retail, and field operations are moving to offline-first apps because connectivity is unreliable and latency kills workflows. Browser storage APIs are maturing. CRDT frameworks are simplifying sync logic. The developer experience advantages (instant UI feedback, no loading spinners) are impossible to ignore once you’ve built with them.

Kleppmann’s sovereignty argument isn’t just academic. The cloud is a geopolitical risk, and local-first mitigates it. The cost argument isn’t minor. Cloud bills are the fastest-growing line item in IT budgets, and local-first reduces them. The UX argument isn’t a nice-to-have. Users expect instant responsiveness, and local-first delivers.

Local-first isn’t “no cloud.” It’s “low cloud.” The cloud still handles sync, backups, collaboration, and multi-device access. But the primary data lives on the user’s device, under their control, working offline, responding instantly. That’s not a niche use case anymore. That’s where the default is moving.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *