ElectricSQL works best when sync is a read path, not a second write model

A real photograph of the first web server fits this ElectricSQL article because the project deliberately keeps sync on ordinary web infrastructure: Postgres changes are shaped, exposed over HTTP, and consumed by clients rather than hidden inside a new application platform.[8]

ElectricSQL is easiest to misread if you approach it as a full local-first application framework. The more useful adoption frame is narrower: Electric is read-path sync infrastructure for Postgres. It takes selected database state, turns it into shape streams, and lets clients consume those streams over HTTP while the existing application continues to own writes, authorization, and business rules.[1][2][3]

That narrower reading is not a downgrade. It is the reason Electric has become interesting again. Many teams want a faster, more local-feeling UI without replacing Postgres, rewriting their mutation layer, or signing up for a new all-purpose backend. Electric's current architecture offers a practical middle lane: keep Postgres as the source of truth, use logical replication to follow changes, sync bounded subsets to the edge or browser, and make the client feel less dependent on round trips for every read.[1][2][6]

As of 2026-05-18T09:32:44Z UTC, the GitHub API reports 10,187 stars, 331 forks, 296 open issues, an Apache-2.0 license, and a most recent push timestamp of 2026-05-18T09:30:51Z for electric-sql/electric.[4] The releases feed shows fresh package tags on 2026-05-13, including [email protected].[5] Those numbers do not prove fit on their own, but they do show a live project with enough operator attention that the adoption question should be architectural, not whether the repository is asleep.

Image context: the cover photograph shows the NeXT workstation used by Tim Berners-Lee as the first World Wide Web server.[8] ElectricSQL is not about that machine historically, but the image is a useful visual anchor: this article is about keeping sync legible as web infrastructure. The interesting part is not a new diagram. It is the old problem of making networked state available through a boundary operators can understand.

1. Start with Shapes, because they are the adoption unit

The key primitive in Electric is the Shape. The docs define Shapes as the way Electric syncs little subsets of Postgres data into local apps and services: a table, an optional where clause, and optional columns define what a client should receive.[2] That is the right unit for adoption planning. A team should not begin by asking "Can we sync the app?" It should ask "Which slices of data are stable, useful, and safe enough to sync?"

That question immediately exposes the real boundaries. Shapes are currently single-table, although subqueries can be used in preview for related-data filtering, and shape definitions are immutable.[2] Where clauses support many ordinary PostgreSQL operators and functions, but not every PostgreSQL feature. JSONB, full-text search, geometric, network-address, and range operators are listed as unsupported in the Shapes guide.[2] Those limits matter because they stop Electric from becoming invisible magic. If the local view depends on complicated server-side semantics, you have to decide whether to simplify the shape, use a backend endpoint, or wait for feature support.

This is why Electric fits best where the read model can be made explicit. Task lists, dashboards, edge caches, agent context, analytics views, and collaborative app panels often have natural subset boundaries: a project, account, workspace, organization, device, or visible slice of a table.[1][2] The weaker fit is a product whose every screen depends on arbitrary cross-table query semantics that have never been written down as a sync contract.

2. Treat writes as a deliberate non-feature

The writes guide is blunt in a helpful way: Electric does read-path sync and does not provide or prescribe built-in write-path sync back into Postgres.[3] That sentence should be part of every migration plan. Electric is not asking your team to move mutations into a new distributed protocol. It is asking you to keep writes in your API, then let Postgres changes flow back out through sync.

That design is excellent when writes already need centralized validation: payments, permissions, inventory changes, server-side workflows, AI jobs, audit trails, or anything else where "just merge the local mutation later" is too casual.[3] The UI can still use optimistic state, but the canonical write decision remains behind the application's existing endpoint.[3][7]

The tradeoff is equally clear. If your product needs true offline writes with complex conflict resolution as the central feature, Electric is not a complete answer by itself. You will need an outbox, optimistic mutation model, conflict policy, or another local-first layer around it.[3][7] That is not a failure of the tool. It is the architectural bargain. Electric lowers the cost of live local reads; it does not make distributed writes free.

3. Keep authorization outside the sync engine

Electric's auth guide recommends routing requests through a proxy or middleware stack so the application can authorize shape access before the request reaches Electric.[6] In the simple proxy pattern, the application validates credentials, sets the shape parameters server-side, and streams the authorized response back to the client.[6] In the gatekeeper pattern, the API issues a shape-scoped token that a proxy validates against the requested shape.[6]

That arrangement is important because synced data is usually more dangerous than fetched data. A normal endpoint can return one response. A shape stream can continue delivering changes as the underlying table changes. If a client can choose its own table and where clause without server control, the sync layer becomes a data-exfiltration surface.[2][6]

So the adoption checklist should put authorization before client polish. Which backend route owns each shape? Which parameters are fixed server-side? Which user-supplied filters are allowed only to narrow results? Which shape-scoped tokens expire, and what happens when group membership changes? Electric's docs make this explicit enough that teams should resist the shortcut of exposing /v1/shape directly to a public client.[6]

4. Price the operational surface honestly

Electric deploys as an Elixir web service packaged in Docker, connected to Postgres through DATABASE_URL.[1][7] The deployment guide says Postgres must be version 14 or above, logical replication must be enabled, and the database role needs replication privileges.[7] It also warns that direct Postgres connections are usually needed because most connection poolers do not support logical replication, although pgBouncer support may change that boundary over time.[7]

There is also a storage surface. Electric creates a publication and replication slot, keeps active database connections open, and caches shape logs and metadata on a persistent filesystem.[7] The docs rank disk speed as the top optimization factor, ahead of memory and CPU, for hosts serving Electric.[7] That matters for planning. Electric may remove bespoke polling endpoints and reduce client waterfalls, but it adds a real sync service with disk, replication, cache, and upgrade responsibilities.

The operational payoff is that the runtime speaks HTTP. The HTTP API supports initial shape sync and live updates through long polling, with Server-Sent Events available as a more efficient live mode.[1] That keeps the client boundary easier to inspect than a proprietary binary protocol. It also makes CDN and edge proxy patterns plausible when the authorization design is sound.[1][6]

5. Use TanStack DB and PGlite as fit signals, not prerequisites

Electric's ecosystem now points toward a broader local-data stack. The Electric docs list PGlite examples and TanStack DB integration, while TanStack DB describes itself as a reactive client store that can load data into normalized collections, run live queries, and use sync engines such as ElectricSQL as collection sources.[1][2][7]

That is a useful signal, but it should not become cargo cult. Electric can be consumed through the HTTP API, through the TypeScript client, through React hooks, or through higher-level collection systems.[1][2] The correct client layer depends on how much local query behavior the app needs. If components mainly need a live list or detail view, useShape and a thin store may be enough. If the app needs local joins, optimistic collection mutations, derived views, or query-driven loading, TanStack DB becomes more attractive.[2][7]

The same discipline applies to PGlite. Embedded Postgres in the client can be powerful, especially for richer local state or test/dev environments, but it is not required for every Electric deployment.[1] Start with the sync boundary first. Add a heavier local database only when the app's offline, query, or agent-workload needs justify it.

Bottom line

ElectricSQL is strongest when a team treats sync as an explicit read-path layer, not as a replacement application platform.[1][2][3] The migration path should begin with a few bounded Shapes, route them through a backend-controlled auth proxy, keep writes in the existing API, and measure the operational cost of logical replication plus shape-log storage before expanding the surface.[2][3][6][7]

The failure mode is overclaiming. Electric can make Postgres-backed applications feel faster and more local, but only if the data slices are well chosen and the write/auth boundaries stay visible. Used that way, it gives teams a pragmatic route toward local-feeling software without pretending every product needs to become a bespoke distributed database.

cronfeed.work