Updated 6 Sep 2026: Neon's branch-aware backend has expanded beyond its original US-only beta footprint. The September 4 changelog adds AWS Europe (Frankfurt) alongside AWS US East (Ohio), materially changing latency/data-location options for Functions, Object Storage and related backend services while leaving the branchable architecture and beta boundaries intact.
Key details
- Neon Functions entered beta on August 17, 2026.
- Functions run Node.js 24 in the same region and branch context as Neon Postgres.
- Neon Object Storage is S3-compatible and participates in branch workflows.
- On September 4, Neon added AWS Europe (Frankfurt) backend availability alongside AWS US East (Ohio).
- The expansion applies to the branch-aware backend stack rather than changing its core architecture.
- Functions and Object Storage remain beta and final long-term pricing/service boundaries are still subject to change.
What builders should take away
- European teams can re-test preview and agent workflows in Frankfurt instead of accepting the original U.S.-only latency path.
- Keep database, Functions and Object Storage in the same intended region when branch-locality is part of the design.
- Do not infer full regulatory data residency from the Neon region alone; audit every external dependency and data transfer.
- For coding agents, use disposable branches plus scoped third-party credentials so the regional backend sandbox does not become a bridge into shared production services.
- Revisit cost models when Neon publishes final GA pricing for Functions and Object Storage.
- Retest logs, failure handling and branch create/reset/delete flows before moving critical workloads onto the still-beta stack.
What changed
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, while its S3-compatible Object Storage extends branch workflows to file data. On September 4, Neon expanded the backend beta from its original AWS US East (Ohio) footprint to AWS Europe (Frankfurt). That means projects using the branch-aware backend stack can now place Postgres-adjacent Functions, Object Storage and related backend services in `aws-eu-central-1` as well as `aws-us-east-2`, reducing the original U.S.-only constraint without changing the underlying branchable architecture.
Why it matters
Database branching is most useful when the rest of the application can follow the same environment boundary. Neon’s Functions and Object Storage already made previews and agent-created environments more complete; Frankfurt makes that model more practical for European teams that care about latency or regional placement. The expansion is still not a GA or compliance guarantee: these services remain beta, and builders still need to verify durability, observability, pricing and whether their complete data path satisfies residency requirements.
The backend stack now has two regional homes
Neon’s September 4 changelog adds AWS Europe (Frankfurt) to the original AWS US East (Ohio) backend availability. Teams can choose a region closer to European users or development infrastructure instead of routing every Functions/Object Storage workflow through the U.S.
Functions still run beside the database branch
Neon Functions are Node.js 24 functions associated with the same Neon branch and region as Postgres, with a branch-specific `DATABASE_URL` injected automatically. The runtime supports HTTPS endpoints, streaming, Server-Sent Events and WebSockets.
Object Storage keeps branch semantics for files
Neon’s S3-compatible Object Storage participates in branch workflows so child environments can carry isolated object state alongside Postgres. That is especially useful for tests, preview deployments and coding agents that should not mutate shared production files.
Regional expansion changes the original beta constraint, not the maturity level
The earlier backend beta was explicitly region-limited. Frankfurt removes that specific limitation, but it does not make Functions or Object Storage generally available or settle their final production pricing, support model, log retention or service guarantees.
Regional placement is not the same as full data residency
A Frankfurt Neon backend can reduce latency and keep Neon-owned resources in a European region, but applications may still call external queues, payment systems, model APIs or other services elsewhere. Teams with residency requirements need to map the full application data path rather than treating one regional setting as a complete compliance answer.
What to watch next
- Further regional expansion beyond Ohio and Frankfurt.
- GA timing and production SLAs for Neon Functions and Object Storage.
- Final pricing and metering for function execution, object storage, egress and branch copies.
- Improvements to logs, metrics and retention beyond beta defaults.
- Whether Functions gain durable background-job/event primitives or remain primarily request/streaming compute.
- Formal residency or compliance guarantees attached to regional backend placement.
Still unclear
- Functions and Object Storage remain beta, so limits, pricing and APIs may change before GA.
- Regional placement improves locality but does not by itself establish end-to-end data residency or compliance.
- Neon’s performance and workflow claims are based primarily on its own product material; BTN has not found independent large-scale benchmarks for the branch-aware backend stack.
- Branch semantics cover Neon-owned resources, not external SaaS dependencies or credentials.
Sources
Direct reading behind this dossier.
Discussion
Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.
Join the discussion
Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.
Sign in to comment