Neon Functions puts Node.js compute on Postgres branches for AI agent backends

Neon has launched Neon Functions, a compute service that runs Node.js 24 workloads directly on a Neon branch, in the same region as its Lakebase Postgres database. The database connection string is injected automatically at runtime. The company announced the product on August 17, 2026, presenting it as an early piece of a broader “Neon backend” that combines Postgres with Object Storage, Functions, Auth and an AI Gateway.

For developers building AI agent backends on Postgres, the main promise is removing the cross-region hops and short runtime caps that usually push long-lived workloads onto separate infrastructure.

What Neon announced

Neon’s argument is that a database alone is not enough for applications built today, especially when a coding agent ships an entire app. According to the company, Functions targets three frustrations in typical serverless setups: every query pays a cross-network round trip, developers wire secrets themselves, and runtimes often cap at a few seconds.

Functions run on the same infrastructure as Postgres and read the branch’s DATABASE_URL from process.env. If the project also uses Neon’s AI Gateway or Object Storage, those credentials are injected as well, so developers do not need to assemble separate accounts. Because the runtime stays up across requests, a function can keep a long-lived pg Pool open instead of opening a fresh connection on every invocation the way edge-style handlers often do.

Designed for agents and real-time connections

The longer runtime is aimed squarely at AI agent workloads. One agent request can remain active for minutes while the agent calls models and tools, and Neon says Functions is long-running enough for those loops, as well as for WebSockets and SSE connections that stay open while data flows.

A function can export an upgrade handler for WebSockets or return text/event-stream for SSE, and fan out across isolates using Postgres LISTEN/NOTIFY instead of standing up Redis. Neon draws a clear line at background jobs: a function is always requested and always returns a web response such as JSON, an SSE feed or a WebSocket upgrade. For queued work with its own lifecycle, the company suggests pairing a function with something like Inngest.

Functions follow the branch

Branching is Neon’s flagship feature, and Functions uses the same model. A Neon branch acts as a lightweight copy-on-write environment of the database, and functions deployed to a branch are tied to that branch_id. Since Neon now also offers Object Storage, Managed Better Auth and an AI Gateway, those primitives branch as well. According to the company, creating a branch duplicates the entire backend instantly, including any deployed functions.

That design is meant to make preview environments more useful: a branch with its own functions, storage and auth can stand in for the full backend during development, then be discarded when the work is merged.

Deployment via neon.ts

Deployment is handled through neon.ts, Neon’s backend-as-code config. A single file can declare Postgres databases, Functions, Object Storage buckets, Auth and the AI Gateway for a branch. A function is any module whose default export provides fetch(request) and returns a Response, with Hono recommended as the framework.

Neon recommends a module-scope pg Pool using the standard pg driver over @neondatabase/serverless, which is built for short-lived, edge-style invocations rather than this long-running model. The service is free during beta on any pricing plan. Templates are available through neon bootstrap –template, with runnable examples on the Build on Neon page and source code on GitHub.

Limits, pricing and what remains unclear

Today, Neon Functions are invoked over HTTP only. The company says the next layer is a declarative invocation surface: function triggers that let Neon call functions from schedules and service events without an external scheduler or app-tier glue. That work is still in progress and, like Functions themselves, will be branch-scoped.

The announcement does not specify production runtime limits, concurrency caps or a timeline for leaving beta. Neon also positions Functions as part of a larger backend rather than a standalone compute product, so developers are expected to combine it with the surrounding primitives. Independent benchmarks were not included in the announcement, so performance claims rest on Neon’s own description. For first tests, Neon points to its Functions quickstart and asks for feedback on Discord.

Source: Neon Blog — Neon Functions: backend logic next to your data (https://neon.com/blog/neon-functions-backend-logic-next-to-your-data)