Electric SQL is no longer just presenting itself as a Postgres sync engine. The first-party site now frames Electric as data primitives and infrastructure for collaborative, multi-agent systems, and the latest release stream backs that up. ToolVitals sees 127 release events in 30 days, 30 GitHub releases in 90 days, and a shipping score of 100. That is the signal: a database-category project is shipping like an agent platform.

What Electric says it is now

The official Electric site redirects from electric-sql.com to electric.ax, and the current top-level positioning is explicit: Electric provides data primitives and infrastructure for collaborative, multi-agent systems. The same page lists hosted products and sync primitives side by side: Electric Streams, Electric Sync, Postgres Sync, TanStack DB, and PGlite.

That matters because the old mental model, Electric equals local-first Postgres sync, is too narrow. The Postgres Sync page still defines the core engine in plain terms. It is a read-path sync engine for Postgres that handles partial replication, data delivery, and fan-out. It connects to Postgres through DATABASE_URL, consumes the logical replication stream, and fans data out into Shapes.

The GitHub repository says the same thing from the developer side. Its README describes Electric as a Postgres sync engine that solves partial replication, fan-out, and data delivery, then adds a sharper implementation detail: the core sync protocol is a low-level HTTP API that can integrate with CDNs for scalable delivery. Partial replication is managed through Shapes, and sync can be consumed directly or through clients and integrations.

Shapes are the important primitive. Electric’s Shapes guide defines a shape as a subset of Postgres data to sync into a local app or service. A client can sync one shape or many. Many clients can sync the same shape. Shapes can overlap. That is not just a documentation detail. It is the design hinge between database replication and application-level coordination.

Electric Streams pushes the same coordination idea into agent workflows. The Streams page describes every prompt, tool call, and generation as an event appended at a known offset on a persistent, real-time stream. It also says streams are not single-consumer. Multiple agents and humans can attach to the same stream, see events arrive, and resume from offsets.

Interpretation: Electric is trying to make sync the substrate beneath both apps and agents. Postgres Sync moves data out of the database. Streams preserve the event trail of agent activity. TanStack DB gives the client a reactive store with local queries and optimistic interaction paths. PGlite puts a lightweight WASM Postgres inside JavaScript runtimes. Those pieces point at one product direction, not four unrelated side projects.

The ToolVitals metrics are unusually loud

ToolVitals gives Electric SQL a hot score of 225.1, a health score of 93, a shipping score of 100, and a ToolVitals score of 97. The repository has 10,234 GitHub stars. ToolVitals also records 30 GitHub releases in 90 days and 127 release events in 30 days, with data confidence at 100.

Those numbers say activity is not the question. Electric is shipping often, across multiple packages, and with enough public signal for ToolVitals to score it confidently. A shipping score of 100 is not a promise that the software is production-ready for your workload. It is a signal that the project is alive, maintained, and pushing visible release artifacts at a fast pace.

The caveat is just as important. Electric’s 127 release events in 30 days do not mean 127 major product advances. The recent events include multiple package releases on the same date, including desktop, mobile, runtime, server UI, and server packages. In a monorepo, one product change can generate several package releases. Treat the number as a velocity signal, not a feature-count scoreboard.

The health score of 93 and ToolVitals score of 97 make Electric look strong, but they should not be read as code quality scores. ToolVitals sees public activity, releases, stars, uptime and availability style signals where available. It does not run your workload, review architectural tradeoffs, or audit correctness under failure.

Electric is OSI-approved open source under Apache-2.0 according to the ToolVitals openness field and the repository license signal. That distinction is useful for teams that need permissive licensing and want to inspect or self-host critical sync infrastructure.

The recent releases are mostly about agents

The June 15 release cluster is the most interesting part of the evidence. The Electric Agents Desktop v0.1.18 release adds streamed model reasoning and extended-thinking content into the UI. The release notes describe live reasoning text shown above the answer, elapsed-time display, collapsed settled reasoning, separate reasoning rows per tool-using run, and provider handling for Anthropic, DeepSeek-R1, Moonshot K2, and OpenAI Responses summaries.

That is not a database engine feature. It is an agent product feature built on top of the data model and timeline.

The matching @electric-ax/agents-runtime@0.4.0 release carries the same reasoning-streaming work into the runtime. The runtime notes talk about schema changes, reasoning deltas, bridge callbacks, adapter routing for thinking events, and timeline rows with live reasoning collections. The implementation detail matters because it shows Electric treating agent runs as structured, persisted, replayable data rather than transient UI text.

The @electric-ax/agents-runtime@0.4.1 release is even more revealing. It renames experimental webhook-source APIs, requires an explicit Electric shape endpoint URL for pg-sync observations, derives source identity from shape options plus tenant, principal, and entity, validates the endpoint by fetching the shape log up front, and adds an unobserve_pg_sync tool. That reads like infrastructure for agents that wake on database-shaped changes without losing scoping rules.

The @electric-ax/agents-server@0.5.0 release adds externally writable custom collections for agent entity state. Writes go through an authenticated schema-validated endpoint, stamp the principal into a read-only _principal column, and can be projected into the timeline through custom sources. Comments are reimplemented as one such collection, with insert-only behavior.

The @electric-ax/agents-mobile@0.0.16 release adds mobile session sharing. It includes a share session screen, people-with-access list, workspace-wide general access, role controls, copy session id, and session web links aimed at the agent UI path. Again, this is product work around collaborative sessions, permissions, and shared agent state.

Evidence: the first-party release notes are about reasoning streams, pg-sync observation, custom collections, handler errors, response parsing, auth-header preservation, and session sharing. Interpretation: Electric is not merely adding AI branding to a sync engine. It is using the sync engine as the backing model for collaborative agent sessions.

Why this matters technically

Most agent products start with chat logs and bolt state management on afterward. Electric appears to be going the other direction. It starts from synced state, durable streams, shape-scoped replication, and local reactive clients, then builds agent interaction on top.

That is a serious architectural bet. If your agent needs to observe a subset of Postgres, wake on changes, preserve a timeline, expose reasoning, share sessions across users, and keep local UI reactive, then sync is not a nice extra. It is the system boundary.

The Postgres Sync docs support this read. Electric is designed to sync subsets of data out of Postgres into local apps and services. The Shapes guide explains how to define those subsets. The Streams page frames durable event streams as the agent loop. The GitHub README describes the HTTP sync API and CDN-friendly data delivery. Together, the pieces line up around fan-out, replay, and coordination.

A skeptical buyer should care less about the agent demos and more about the shape of the primitives. Ask whether your team can model its authorization boundaries as Shapes. Ask whether read-path sync is enough, since Electric’s own positioning separates read-path sync from write-path patterns. Ask how operationally comfortable you are running a sync service in front of Postgres with logical replication enabled. The repository README says that is the basic setup path, not an incidental detail.

What the data does not tell you

ToolVitals can say Electric is visible, active, healthy by public signals, and shipping very fast. It can say the project has 10,234 stars, 30 GitHub releases in 90 days, and 127 release events in 30 days. It can say the license signal is Apache-2.0 and OSI-approved open source.

ToolVitals cannot say the sync engine will behave correctly under your production write load. It cannot say your authorization model maps cleanly to Shapes. It cannot say agent reasoning streams are the right UX for your users. It cannot infer revenue, support quality, customer satisfaction, or long-term roadmap discipline from public release activity alone.

There is also a monorepo interpretation risk. Electric’s public release stream includes core sync, agent runtime, desktop, mobile, server UI, and server packages. That is good if you want an integrated platform. It is noise if you only care about the stability of Postgres Sync itself. Buyers should separate core sync releases from Electric Agents package releases during evaluation.

For maintainers, the message is clear: the public story should keep separating primitives from products. The site does a decent job by listing Postgres Sync, Streams, TanStack DB, and PGlite distinctly. The release feed is harder to read because agent package releases dominate the recent window. If Electric wants database buyers and agent builders at the same time, release notes need strong labels and migration guidance so buyers can tell what affects their deployed sync service.

Competitive context

Among related database tools in the ToolVitals payload, Electric has fewer stars than ClickHouse and Weaviate but more 30-day release activity. Electric has 10,234 stars and 127 release events in 30 days. ClickHouse has 48,045 stars, a hot score of 220.5, and 71 release events in 30 days. Weaviate has 16,335 stars, a hot score of 207.9, and 19 release events in 30 days.

That comparison should be read narrowly. ClickHouse is an analytical database. Weaviate is a vector database. Electric is a Postgres sync and agent-infrastructure project. The shared category is databases, but the jobs are different.

The useful comparison is momentum versus maturity. ClickHouse has far more stars and a large established user base signal. Weaviate also has more stars than Electric. Electric’s stronger 30-day release-event count suggests faster visible iteration, not greater adoption. If you are choosing a database engine, that comparison is mostly apples to sockets. If you are tracking infrastructure for live local data and agents, Electric’s velocity is the notable part.

The broader related-tools list shows how high the bar is for attention. LangChain has 139,473 stars and a hot score of 239.7. Astro has 60,214 stars and 73 release events in 30 days. Electric is smaller by stars, but it sits surprisingly close in hot score because ToolVitals is picking up recent public motion.

Recommendation

Evaluate Electric SQL if your team is building Postgres-backed software where many clients, services, or agents need scoped, low-latency views of changing data. The strongest fit is not generic database replacement. It is read-path sync, partial replication, fan-out, collaborative sessions, and agent workflows that need durable, replayable state.

Do not evaluate it only by the 127 release events. Use that number to justify a serious look, then test the primitives. Build one Shape that matches a real authorization boundary. Run the sync service against a Postgres database with logical replication enabled. Exercise the HTTP API. Try a client path with TanStack DB or PGlite only if those match your app architecture.

If your team is mainly looking for a stable analytical database, pick a tool built for that job. If your team is trying to make agents and humans coordinate over live Postgres-backed state, Electric deserves a proof of concept now, because its public roadmap and release activity are converging on exactly that problem.

Sources