By ByteBot
Neon stopped being just a database last Thursday. The company announced three new services — serverless functions, S3-compatible object storage, and an AI gateway that proxies calls to OpenAI, Anthropic, and Gemini — all running on the same branchable infrastructure as its Postgres. Early access is open. GA is expected in Q3 2026.
This is the most significant expansion in Neon’s history, and it’s worth understanding why the architecture matters more than the feature list.
One Backend, Every Branch
The conventional wisdom about Neon has always been: fast serverless Postgres, excellent branching, good for preview environments. That’s still true. But the new announcement rewrites what “branching” means.
When Neon creates a branch today, only the database forks. Starting in Q3 2026, creating a branch will fork everything: the database, the storage bucket, and the deployed function code. Every pull request, every test environment, every agent sandbox — isolated copies of the full backend, not just the DB schema.
No other platform does this. Supabase branching gives you an isolated database. Neon is betting that developers will eventually want isolated infrastructure — and that the branchable model should extend to every stateful thing in a project.
Over 80% of databases on Neon are already created by AI agents, not humans. That number makes the platform bet legible: when AI agents spawn thousands of short-lived environments, you need infrastructure that can fork and destroy instantly. Neon’s copy-on-write storage makes branches nearly free.
Four Services, One CLI
Here is what Neon is building toward:
Postgres (Already GA, PG18 Now Default)
As of the June 5 changelog, new Neon projects default to Postgres 18. This brings async I/O (2-3x faster for I/O-bound queries), native UUIDv7, virtual generated columns, and an improved RETURNING clause that exposes both OLD and NEW row values. If you created a project last month, you were on PG17. New projects today are on PG18 automatically.
Serverless Functions
Neon’s functions run without timeouts and close to your database. That last part matters more than it sounds: latency between a function and its database is a real bottleneck in multi-region deployments. Neon sidesteps this by collocating compute next to storage. Functions are managed via the same CLI and API as everything else — no separate serverless account, no context switching.
Object Storage (S3-Compatible)
Standard S3-compatible storage — but it branches. Your media files, uploads, and generated artifacts follow the same branch lifecycle as your database rows. If you branch for a PR, the storage bucket branches too. Existing S3 tooling works unchanged.
AI Gateway (LLM Proxy)
This is the one that changes the calculus. The AI Gateway routes, logs, and rate-limits calls to OpenAI, Anthropic, and Gemini. Streaming responses are included. Per-request logging is built in. And it runs on Databricks’ infrastructure — the same layer that processes 125 trillion tokens per month for enterprise customers.
That last detail is not a footnote. Databricks acquired Neon for approximately $1 billion in 2025 to make it the database layer for AI agents. The AI Gateway isn’t a weekend project; it’s backed by infrastructure hardened across enterprise requirements for availability, logging, and cost controls that most developers can’t afford to build themselves.
The Supabase Question
Anyone evaluating Neon’s new platform will ask: isn’t this just Supabase?
The honest answer: Supabase already has all of this. Auth, Edge Functions, Storage, and Realtime have been GA on Supabase for years. The ecosystem is more mature, the dashboard is better, and the community is larger.
Where Neon is different — not just different for marketing purposes, but architecturally different — is in how serverless is implemented. Supabase’s serverless is about abstraction: traditional Postgres under the hood, with serverless services layered on top. Neon’s serverless is structural: compute and storage are physically separated, which is what enables true scale-to-zero and instant branching.
The HTTP/WebSocket driver (@neondatabase/serverless) also means Neon works in environments where TCP connections are unavailable — Cloudflare Workers, Vercel Edge — without any additional configuration. Supabase requires workarounds for the same.
The AI Gateway backed by Databricks is Neon’s only structural advantage Supabase cannot easily replicate. For teams building AI-heavy apps that need managed LLM routing with enterprise-grade observability, this is worth watching closely.
Getting Started Now
The new services are in early access. Functions, storage, and the AI Gateway are not yet GA. To get notified when they ship, sign up at neon.com/blog/were-building-backends. For the Postgres features already available:
# Install Neon CLI
npm install -g neonctl
# Link current directory to your Neon project
neon link
# Create a branch for your feature or PR
neon branches create --name feature-branch
# Checkout and work in that branch
neon checkout feature-branch
# Connect directly via psql
neon psqlThe Bottom Line
Neon is 2-3 years behind Supabase on platform completeness. That gap is real, and teams who need Auth, Storage, and Edge Functions today should still default to Supabase or an established alternative.
But Neon’s architecture makes eventual parity more powerful than what Supabase can offer. A backend where every service branches together — database, storage, functions, AI gateway — is a different product category than “Postgres plus some extras.” Neon is building toward that. Databricks is funding it.
Sign up for early access if you’re building AI agents or applications with heavy LLM usage. The AI Gateway alone, backed by enterprise infrastructure at no extra setup cost, is worth the notification.
