On August 11, 2026, Electric announced it is joining Neon at Databricks. In the same post it said, plainly, “Electric Cloud is winding down.” Customers “will need to self-host or move to another provider.” The post gives no shutdown date. It says the team has contacted Cloud users directly.

If you build local-first software, read that twice. The pitch for local-first is that the user’s data lives on their device and the app keeps working when a company disappears. That pitch is true for the data. It is much less true for the sync layer, which is where most teams quietly add a new dependency.

What actually happened

Electric makes a sync engine for Postgres, plus PGlite (Postgres in the browser) and a few related libraries. Databricks bought Neon in 2025, and now Electric’s team is folding its work into Lakebase, Databricks’ Postgres service, aimed at AI agent workloads.

The open-source pieces stay open source. Electric named Postgres Sync, PGlite, TanStack DB, and Durable Streams. That is good news and we don’t want to downplay it. Nobody’s code stops compiling.

But the hosted service is the part many small teams actually used. Running a sync engine in production means running a service, with replication slots and auth proxies and upgrades that someone has to own. Paying someone else to do that is a reasonable choice. It is also a choice to depend on them.

This is not new. MongoDB deprecated Realm’s Atlas Device Sync in 2024 and shut the service down on September 30, 2025. Teams that had built offline-first mobile apps on it had to rework their data layer on a deadline. The local database kept working. The sync stopped.

The part of local-first people skip

Here is the honest breakdown of what you own in a typical local-first app.

The data on the device: yours. The schema: yours. The UI: yours. The sync protocol and server: usually someone else’s, and a sync vendor is a business like any other, with investors, a roadmap, and the chance of being bought. Electric just showed what that looks like.

We’re not saying avoid them. Writing sync from scratch is a bad idea for most products. Conflict resolution is subtle, and we’ve seen teams burn months on it. What we push back on is treating the sync vendor as infrastructure you never have to think about. It is a vendor in the same sense your payment processor is.

The failure mode is also quieter than a normal outage. Your app still opens. Users still see their data. Edits just stop reaching other devices, and nobody notices until a customer asks why the tablet and the phone disagree.

Four questions to ask before you pick one

We ask these on every project that needs multi-device sync.

Can we run it ourselves, today, on a plain VM? Not “in theory.” Someone on the team should be able to stand it up from the repo and the docs in an afternoon. If the answer is “the self-hosted version is a different, older codebase,” treat the hosted service as the real product.

Does it sync to a database we already own? Electric’s model is the right shape here, and this week shows why. Your Postgres is the source of truth, and the sync layer reads from it. When the hosted service goes away, your data is already in a standard database with standard backups. Customers have a migration to plan, not a recovery. Compare that with a service where the server-side copy lives in a proprietary store.

Is the client format boring? If the on-device data is SQLite or plain JSON, you can read it with ordinary tools. If it needs the vendor’s SDK to open, you’ve built lock-in into the user’s phone.

How many weeks is the exit? Write down how long it would take to replace the sync layer, and what the app does during that time. Ours is usually a read-only mode with a banner. That’s not glamorous, but it beats a silent divergence.

What we’d do differently on a new build

For a product with a small number of writers per record (a field-service app, say, or a clinic tool), plain HTTP endpoints with a queue of pending changes on the device get you surprisingly far. Last-write-wins with timestamps per field handles more cases than people admit. You own every line, and nobody can acquire it.

For products with real concurrent editing, a sync engine earns its place. In that case we pick one with a permissive license and a Postgres backend, and we run it on infrastructure the client controls, in their own cloud account, defined as code. A hosted tier is fine as a convenience, but never as the only way it runs.

We also keep the sync layer behind a thin interface in the app. Screens talk to a local store. One module talks to the network. Swapping engines then costs a few weeks of work in that one module, which is the same exit we write down in question four, and not a rewrite across the codebase.

There’s a counterargument and it’s fair: self-hosting a sync engine is real operational work, and a two-person startup may be better off renting. Agreed. Rent it, but rent it knowing the lease can end. Budget a week a year to test the exit.

Local-first protects your users’ data from your servers going away. It does not protect your product from your vendors going away. Those are separate risks, and the second one just got a fresh example.

This is the thinking behind our local-first software work: the device holds the data, the database is one you own, and every network dependency has a documented way out. If you’re weighing a sync architecture for a product, get in touch and we’ll tell you honestly whether you need an engine at all.