# Electric SQL: status and replacement research (2026-09-10)

Research for arbe-08bc, gathered by a web-research agent; the decision is in that task.

# ElectricSQL status and replacement options for arbe

Researched 2026-09-10 with firecrawl, GitHub API, npm registry, Docker Hub.

## 1. What happened to ElectricSQL

### Acquisition
- **Databricks acquired Electric (Electric DB Inc.), announced 2026-08-11.** The team joins the Neon team inside Databricks (Databricks bought Neon in May 2025). So "acquired by Neon" is close but not exact: the buyer is Databricks, and Electric now sits within Neon at Databricks, working on Lakebase Postgres. Terms undisclosed.
  - Electric's own post: https://electric.ax/blog/2026/08/11/electric-joining-databricks (2026-08-11)
  - Databricks post: https://www.databricks.com/blog/electric-joins-databricks-bring-wasm-postgres-ai-agent-sandboxes (2026-08-11)
  - Neon post: https://neon.com/blog/electric-joins-neon (2026-08-11)
  - Press: https://www.blocksandfiles.com/ai-ml/2026/08/12/oh-no-not-another-one-databricks-buys-electric/5286721 (2026-08-12)

### Electric Cloud (the hosted service you use via ELECTRIC_SOURCE_ID/SECRET)
- Electric's post says: "Electric Cloud is winding down. Cloud users will need to self-host or move to another provider. We've contacted every existing cloud user directly." (https://electric.ax/blog/2026/08/11/electric-joining-databricks, 2026-08-11)
- The dashboard login page today reads: "Electric is joining Databricks and Electric Cloud is winding down — new signups are closed, but existing users can still sign in." (https://dashboard.electric-sql.cloud/, fetched 2026-09-10)
- **I could not find a published shutdown date anywhere public.** The "2026-09-10" date the owner mentions is not on the website, blog, pricing page, dashboard, or GitHub. It most likely came from the direct email Electric sent to cloud users. Treat the email as the authority. A maintainer PR "Remove mentions of Electric Cloud from the sync/quickstart page" was opened 2026-09-07 (https://github.com/electric-sql/electric/pull/4798), which matches a wind-down in progress right now.

### Open-source sync server and `@electric-sql/client`
- "Everything Electric has previously open sourced stays open source: Postgres Sync, PGlite, TanStack DB, Durable Streams." (Electric post, 2026-08-11)
- The repo is very much alive: last commits 2026-09-09, 10.4k stars, 253 open issues, not archived (https://github.com/electric-sql/electric, GitHub API 2026-09-10).
- Releases are still flowing: `@electric-sql/client@1.5.28` published 2026-09-09 (npm registry); `@electric-sql/react@1.0.57`, `@electric-sql/y-electric@0.1.54` same day (GitHub releases).
- Docker image `electricsql/electric` tags: `1.8.1` on 2026-09-07, `1.8.0` on 2026-09-01, `canary` on 2026-09-09 (Docker Hub). So self-host images are current.
- `@tanstack/electric-db-collection@0.4.7` published 2026-08-31 alongside `@tanstack/db@0.8.7` (npm). Kyle Mathews (Electric CPO) is the TanStack DB lead; TanStack DB is under the TanStack org, not Electric, and continues.
- The self-host deployment guide still lists Supabase as a supported Postgres and documents Fly.io deployment (https://electric.ax/docs/sync/guides/deployment, fetched 2026-09-10).

**Verdict: self-hosting the Electric sync server is viable today and actively maintained (weekly releases through 2026-09-09).** The unknown is medium-term: the team's stated direction is "building with Neon inside Databricks" and Lakebase. Expect the open-source server to keep working, but expect roadmap and Supabase-specific attention to fade, and the hosted option is gone.

### Durable Streams
- Named explicitly in the "stays open source" list (Electric post, 2026-08-11). Protocol is MIT, separate GitHub org `durable-streams` (https://github.com/durable-streams/durable-streams).
- Activity is lower than the sync repo: last release `@durable-streams/server@0.3.7` / `state@0.3.1` on 2026-06-03; npm `@durable-streams/server` latest is 0.3.8 from 2026-07-16; last commit 2026-07-16, last push 2026-08-12; 1.7k stars; issues and protocol proposals still being filed as of 2026-09-01 and 2026-09-08 (GitHub API 2026-09-10).
- Deployment options per https://durablestreams.com/deployment (fetched 2026-09-10): Node reference server (`@durable-streams/server`, "for development, testing, prototyping"), a Go Caddy plugin ("for production deployments"), and Electric Cloud (now closing). The docs still point at Electric Cloud for managed hosting, so that page is stale.
- **Verdict: arbe's self-hosted durable-streams on Fly is not directly affected by the Cloud shutdown.** The risk is slower maintenance: no release in ~3 months, and the only "production" server is a Caddy plugin. If you run the Node server in production, note the docs themselves call it a dev/test server. Also note that Electric's product page still markets "Electric Streams" as self-host-or-cloud (https://electric.ax/streams, fetched 2026-09-10), which is inconsistent with the wind-down and shows the site hasn't been fully updated.

## 2. Replacement options for (A) that keep TanStack DB in the browser

Context: ~8 single-table collections, each `where house_id = X`, Supabase Postgres with RLS, SvelteKit (`@tanstack/svelte-db@0.3.7`, published 2026-08-31, exists and is current).

### (a) TanStack DB query collections (polling or refetch-on-signal)
- **Maturity:** Core TanStack DB feature. `@tanstack/query-db-collection@1.2.12` (2026-08-31). Docs: https://tanstack.com/db/latest/docs/collections/query-collection (fetched 2026-09-10). Supports `refetchInterval`, `refetchOnWindowFocus`, `refetchOnReconnect`, manual `utils.refetch()`, and `utils.writeInsert/writeUpdate/writeDelete/writeBatch` "direct writes" explicitly intended "to sync real-time updates from WebSockets or server-sent events."
- **Hosting/cost:** none beyond what you already run. queryFn can hit PostgREST via supabase-js or your existing SvelteKit routes.
- **Supabase + RLS:** yes, trivially, since reads go through PostgREST as the user.
- **Migration effort:** lowest. Swap `electricCollectionOptions({ shapeOptions })` for `queryCollectionOptions({ queryFn })` per collection, keep schemas, keys, and mutation handlers. Roughly a few hours for 8 collections. Freshness is polling latency unless you add a signal (see b, or a Supabase Realtime broadcast that calls `refetch()`).
- **Cons:** no true push without extra wiring; polling load scales with open tabs.

### (b) Supabase Realtime feeding a TanStack DB collection
- **Official adapter exists: `@supabase-labs/tanstack-db`** at https://github.com/supabase/tanstack-db (Supabase org, 55 stars, last push 2026-09-07, 11 open issues; npm 0.0.1 published 2026-06-15 and not republished since, so GitHub is ahead of npm).
  - `supabaseCollectionOptions({ tableName, schema, keys, supabase, realtime: true })`.
  - Where/order/limit/joins/aggregates push down to PostgREST (README table, fetched 2026-09-10), so `where house_id = X` becomes a PostgREST filter.
  - README FAQ: "tanstack-db goes through PostgREST and Realtime, so your existing RLS policies apply automatically."
  - README warning: "**Experimental.** The Realtime integration is still being stabilized and may consume more Realtime messages than expected. Test in orgs on the free plan or with a spend cap. Set `realtime: false` on individual collections to opt out." A 2026-09-06 commit fixed unhandled errors from racing INSERT events and channel replays, which tells you the Realtime path is still being hardened.
- **Supabase Realtime (`postgres_changes`) itself:** mature. Server-side filters like `house_id=eq.X` (https://supabase.com/docs/guides/realtime/postgres-changes, fetched 2026-09-10). Caveat: authorization runs per subscriber per event, throughput scales with subscriber count, and delete events only filter with `replica identity full`. Limits (https://supabase.com/docs/guides/realtime/limits): Pro plan 500 concurrent connections and 500 messages/s; fine for an alpha.
- **Hosting/cost:** already included in your Supabase plan. Tables must be added to the `supabase_realtime` publication.
- **Migration effort:** low. Same shape as (a) plus enabling Realtime on 8 tables. Or the DIY version: query collection from (a) plus a hand-rolled `postgres_changes` subscription per house that calls `writeInsert/writeUpdate/writeDelete`. The DIY version is ~50 lines and avoids depending on an experimental 0.0.1 package.
- **Cons:** experimental adapter; Realtime fan-out cost per subscriber; no offline or full local DB semantics (you don't use those today anyway).

### (c) PowerSync
- **Maturity:** production product with a cloud service and a self-hostable open-source service; official Supabase guide (https://docs.powersync.com/integrations/supabase/guide, fetched 2026-09-10); TanStack DB integration exists via a PowerSync collection (https://powersync.com/blog/offline-first-apps-with-tanstack-db-and-powersync).
- **Hosting/cost:** Cloud Free tier (2 GB synced/mo, 50 concurrent clients, projects deactivated after 1 week idle) or Pro from $49/mo (https://powersync.com/pricing, fetched 2026-09-10). Self-host is possible but is another service to run.
- **Supabase + RLS:** works, but it's a different model: PowerSync reads the WAL with a replication role, and read access is governed by PowerSync Sync Streams, not RLS ("generally mirror your RLS setup"). Docs also flag an open Supabase issue with idle instances and WAL growth.
- **Migration effort:** medium-high. New service, sync rules DSL, client-side SQLite, a JWT hand-off, and write-path connector. Overkill for 8 filtered tables when you have no offline requirement.

### (d) Zero (Rocicorp)
- **Maturity:** 1.0 GA in March 2026 per https://zero.rocicorp.dev/docs/status (fetched 2026-09-10); InfoQ coverage 2026-06-08. Roadmap is "largely responsive"; column permissions and Cloud Zero public availability still planned.
- **Hosting/cost:** self-host `zero-cache` (needs Postgres WAL level logical plus two extra Postgres DBs for CVR/change tracking), or Cloud Zero Hobby $30/mo, Professional $300/mo, BYOC $1000/mo (https://zero.rocicorp.dev/#pricing, fetched 2026-09-10).
- **Supabase + RLS:** Supabase is supported with caveats: must use the direct connection, needs Postgres >= 15.8.1.083 for event triggers, `ALTER PUBLICATION` does not fire DDL triggers, may need IPv4 add-on (https://zero.rocicorp.dev/docs/connecting-to-postgres). Zero does not use Postgres RLS; it has its own permissions model (the old RLS-style permissions page is under "Old Stuff / deprecated").
- **Migration effort:** high. Zero replaces TanStack DB with its own client (ZQL) and React/Solid bindings; no first-party Svelte. It is a full sync-engine swap, not a collection swap.

### (e) Self-host Electric
- **Maturity:** actively released (1.8.1 image 2026-09-07, client 1.5.28 on 2026-09-09) but with a team now inside Databricks whose stated focus is Lakebase/Neon.
- **Hosting/cost:** one Elixir container on Fly with persistent disk (shape logs), plus a logical replication slot on Supabase (direct connection, not the pooler). Small Fly machine is a few dollars a month. You already run durable-streams on Fly, so the ops pattern is familiar.
- **Supabase + RLS:** Electric bypasses RLS entirely (it reads the WAL as a replication user); auth is enforced by your SvelteKit proxy, which you already have. Supabase is a documented target (https://electric.ax/docs/sync/integrations/supabase).
- **Migration effort:** lowest in code terms: point ELECTRIC_URL at your Fly app and drop the source id/secret. But it keeps you on a dependency whose hosted product just died and whose roadmap is now someone else's, and adds a stateful service and a replication slot (WAL retention risk if the service goes down).

## 3. Recommendation

1. Delete Electric for the browser collections; replace each `electricCollectionOptions` with a TanStack DB query collection whose queryFn reads through PostgREST or your existing SvelteKit route with `house_id = X`, keeping schemas, keys, and mutation handlers unchanged.
2. Add push with plain Supabase Realtime: one `postgres_changes` channel per house filtered by `house_id`, calling the collection's `writeInsert/writeUpdate/writeDelete` direct writes, with `refetchOnWindowFocus/Reconnect` as the safety net. Skip the experimental `@supabase-labs/tanstack-db` adapter for now, or use it only for collections where you can tolerate its 0.0.1 status.
3. Keep durable-streams self-hosted on Fly as is; it is unaffected by the Cloud shutdown, but pin versions and watch the repo since releases slowed after June 2026.
4. Do not move to PowerSync or Zero: both are full sync-engine swaps with their own permission models and services, which is the wrong trade for an alpha with no offline requirement.
5. If the Cloud cutoff lands before step 1 is done, self-host Electric 1.8.1 on Fly as a stopgap (same client code, new URL), then still finish step 1.