Neon makes Functions and Object Storage branch with Postgres

Neon launched Functions in beta on August 17, adding Node.js 24 backend compute that runs in the same region and branch context as a Neon Postgres database, with `DATABASE_URL` injected automatically and configuration available through `neon.ts`. Earlier in August, Neon detailed S3-compatible Object Storage whose buckets and objects participate in database-style branch workflows. These features build on Neon’s July backend beta, where Postgres, Better Auth, Object Storage, Functions and an AI Gateway were presented as one branch-aware application stack.

Database branching is useful for previews and tests only up to the point where the rest of the application still points at shared services. Neon is trying to extend the isolation boundary so a branch can include backend logic and object data as well as Postgres. That can reduce setup glue for preview deployments, safer agent-created environments and tests that would otherwise risk touching production buckets or shared backend services. The trade-off is deeper coupling to Neon while the products remain beta, with regional, durability, observability and future-pricing details still unsettled.

Neon Functions are Node.js 24 functions exposed over HTTPS and run in the same region as the associated Postgres branch. Neon injects the branch-specific `DATABASE_URL`, which removes a common source of preview-environment configuration drift. The runtime is designed for more than short request handlers: Neon says it can support streaming, Server-Sent Events and WebSockets, including agent loops that stay active for longer interactions.

Neon’s Object Storage is S3-compatible but tied to Neon’s branch model. When a child branch is created, object-storage state can follow the branch instead of forcing every environment to share one external bucket. That matters for tests and previews that need realistic file state: deleting, overwriting or generating objects in an ephemeral branch does not have to touch the production object set.

Neon’s `neon.ts` configuration is intended to define backend resources alongside code. Combined with branch-aware Postgres, Functions and Object Storage, this gives teams a path toward reproducible backend environments that can be created for pull requests, tests or agent tasks and removed afterward. The practical value is less bespoke provisioning logic between database, compute and storage services.

Branchable backend state is particularly useful for coding agents because an agent can be given an isolated environment with realistic data and files, make changes, exercise backend code and then discard the branch. That reduces the temptation to give autonomous tooling broad access to shared development or production services. Builders still need to control external credentials and third-party APIs, which do not automatically become branch-isolated just because Neon resources do.

Neon’s July beta initially limited the broader backend stack to us-east-2 and said Functions and Object Storage would be free during beta, with final pricing to come later. Neon also described short log retention during the beta and noted that Functions are not positioned as a general background-job runner. Teams should therefore treat the current stack as an architectural preview, not assume its present limits or economics are production contracts.