Neon Realtime Public Beta: Any SQL Query as a Live Query, Built for Coding Agents

Neon has put Realtime into public beta. Its announcement, written by Electric co-founder James Arthur, says "Any SQL query can now be a live query. Subscribe to it and the result stays up to date as your data changes." It is free during the beta, has no waitlist, and, as Neon puts it, "your coding agent can set it up in one command."

This is a developer-infrastructure story, but the pitch leans heavily on AI agents: Neon argues that agents are poor at building realtime features when realtime is a separate service, and that moving it inside Postgres fixes the failure mode. Below is what Neon actually shipped, how to try it, and the limits Neon itself lists.

TL;DR: questions developers will ask

What problem is Neon solving?

Neon's post opens with a familiar complaint: realtime "has always had a reputation for demoing well but falling over in production." The usual architecture bolts a separate realtime service next to the database. That service has to mirror every change, in order, through dropped connections. It has its own permissions model and does not know which database branch it is pointed at. And it is one more system to operate.

The post argues this is especially bad for coding agents. Ask an agent for a CRUD app and it usually gets it right; ask it for realtime sync and "the failure rate goes way up." The agent has to set up and keep consistent a second system, which is exactly where generated code breaks.

Neon's answer is to run live queries in the database itself. There is no mirror to keep in sync, no second permissions model and no second system for an agent to configure.

How does it work?

According to Neon, you enable Realtime on a branch, then subscribe to any deterministic, read-only query. The approach differs from most sync systems, which tell you a row changed and leave your app to work out what that means for the screen. Here you subscribe to the exact query your screen shows, and that result stays live.

Neon's example is an unread-count sidebar: a single SQL query joining memberships, channels and messages, grouped by channel, returns channel names with unread counts. Subscribing to that query keeps the sidebar current without polling or refetch logic.

Supported SQL, per the post, includes joins, aggregates, group by, distinct, window functions, subqueries, built-in and user-defined functions and extensions.

Neon also describes how the work is done:

• Scale to zero. Clients connect to Neon's ingress layer, not to Postgres, so open subscriptions do not keep the database awake.
• Branching. Realtime is enabled per branch and child branches inherit it, so a preview branch or an agent's branch gets live queries against its own data.
• Cost. When a write commits, only the live queries it affects are updated. You stop paying to re-run queries on reads and polls, and pay a small incremental cost on writes.
• Primary unaffected. Incremental work runs on a replica, and live queries use no database connections, so the primary's write latency, throughput and compute are not affected.

These are Neon's claims. It says it is not publishing benchmarks yet.

How to try it

From the terminal, Neon's flow is short:

neon realtime enable
neon psql -- -c "CREATE TABLE items (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), value TEXT)"
neon psql -- -c "INSERT INTO items (value) VALUES ('foo')"
neon realtime subscribe "SELECT * FROM items"

Insert another row from a second terminal and the subscribed result updates in place. Add --changes to see the raw delta stream. To set up a whole app, Neon shows neon bootstrap my-app --template realtime-react followed by neon deploy.

In a React component, useLiveQuery binds a component to a live query so it re-renders whenever the result changes. For writes, Neon suggests React's useOptimistic, a call to your API, and awaitTxId to wait for the matching Postgres transaction on the live stream. With TanStack DB, the live query syncs into a collection and the library manages optimistic state.

How does the security model work?

Neon's SDK splits work between backend and subscriber. You define queries on the backend, where your auth already runs, using raw SQL, Drizzle or Kysely, and then seal them with a secret. Neon says a sealed query cannot be forged or modified, so it is safe to hand to a browser or an agent. Parameters such as the user ID come from the request, not the client. Anything with the sealed query can subscribe, whether a browser tab, server or agent.

That design means the client never sends raw SQL. It also means the backend decides which queries a user may see. The post notes row-level security is not yet supported, so for now your own endpoint is the access-control layer. Treat sealed queries like signed URLs: do not seal a query whose parameters a client could manipulate, and do not hand out sealed queries across tenants.

Built for coding agents: what that means

Neon says agents can enable Realtime in one command, test a live query from the terminal, install the Realtime skill with neon skills -s neon-realtime, or use the Neon MCP server. If you are new to skills and MCP, see our explainers on what MCP is and agent skills.

The claim is that agents should reach for realtime by default, the way they add auth or a table. We have not tested how reliably agents do this, and Neon gives no success rates. The plausible mechanism is simpler context: agents already speak SQL and your ORM, so asking for a live query is a smaller step than orchestrating a separate sync service.

Where does this fit in the agent stack?

Realtime is useful for agent products in three ways Neon lists: a task list that shows an agent's progress as it works, a shared board that shows a teammate's edits, and notification counts that update on their own. It also supports agent workflows that react to changes in Postgres directly through Mastra.

For background on event-driven agent patterns, see our guides to MCP events and webhooks and always-on agent architecture. Live queries are a database-level alternative to some of those patterns: instead of an agent polling or receiving a webhook, it subscribes to a result.

How did we get here? The Electric timeline

Realtime on Neon is the product of a short chain of events, all on Neon's own blog.

• Electric joins Neon. Neon announced that Electric, the team behind the PGlite WebAssembly Postgres and the Electric sync engine, was joining Neon within Databricks.
• September 24, 2026: in Electrifying Neon: building the realtime backend, co-founder James Arthur said the aim was for Neon "to have the best realtime, sync and end-to-end reactivity on the market," and that it would work natively with scale-to-zero and branching. He explained the logic of the deal: sync is a feature of a backend platform, and it is better to supercharge a platform that already has a business model.
• October 15, 2026: public beta, three weeks later.

That speed is notable, and so is the framing. Arthur's interview says the playbook for developer-tools startups has changed because "agents are looking for higher-level abstractions." Whether or not you agree, it explains why the launch post spends as much time on coding agents as on human developers.

It also shows a change of emphasis from Electric's earlier design. Neon's guide to Electric describes it as a read-path sync engine that replicates partial subsets of data called Shapes, with writes going through your own API. The new product aims at fully expressive live SQL inside the database, which is a bigger promise and, as Arthur himself notes, historically the hard one to scale.

Limits and what to watch

Neon is candid about the beta:

• Performance will keep improving, and benchmarks are not published yet.
• The protocol is still changing. Use the SDK, not the raw API.
• The console is minimal.
• No row-level security yet.
• Four regions: us-east-1, us-east-2, eu-central-1 and ap-southeast-1.
• Billing nuance: starting a live query can wake your database, so compute and egress are billed even though Realtime itself is free in beta.

Open questions: how it behaves at large subscriber counts, how expensive complex joins and window functions are to maintain incrementally, and what pricing will look like at GA. Neon asks users to "try to break it" and report issues on Discord.

What this means for what you build

If you already use Neon, enabling Realtime on a development branch is a cheap experiment, especially for dashboards, collaborative boards and agent progress views. If you use another Postgres host, this is a signal about where backend platforms are heading: sync, auth, storage and an AI gateway bundled with the database, and designed so agents can configure them. Wait for benchmarks and row-level security before putting sensitive multi-tenant data behind live queries.

Related reading

• What is MCP? The model context protocol guide
• What are agent skills? A complete guide
• MCP events and event-driven agents
• Always-on persistent AI agent architecture
• Cloudflare Artifacts: Git for agents
• Cloudflare Sandbox SDK 1.0 for agents

Details are as stated in Neon's October 15, 2026 announcement and may change during the beta.