Neon's Instant Postgres Branches Need Three Services CNPG Doesn't Have — What Self-Hosting Them on Kubernetes Actually Takes

Ask any of the three most-used Postgres-on-Kubernetes operators — CloudNativePG, the Zalando operator, StackGres — for an instant copy of a database, and they all give you the same answer: provision a new cluster, then restore it from a backup. That's minutes, not milliseconds, and it's a full second copy of the data, not a pointer into shared storage. None of them support copy-on-write branching. It isn't a missing checkbox; it's outside what a Postgres operator is built to do.

Neon does it in under a second, on databases measured in terabytes, because Neon isn't a Postgres operator. It's a distributed storage engine with Postgres bolted on as the compute layer, and "branch" is a metadata operation against that storage — not a copy of anything. It's also increasingly not a human clicking the button: Neon's own telemetry has shown the large majority of databases on its platform get created automatically by AI agents standing up ephemeral environments, not developers filling out a form — exactly the "agent provisions its own infrastructure" pattern a platform built for AI operators has to have an honest answer for. As of mid-2026, there's a real, working way to run that architecture yourself on Kubernetes: a community operator called neon-operator, built by the team behind Molnett. Here's exactly what it requires, what it doesn't do yet, and why the gap between it and CNPG isn't a maturity curve — it's a different category of infrastructure.

Why "Just Add Branching" Isn't an Operator Feature​

CloudNativePG is explicit about the boundary: to get an isolated copy of a database for staging, testing, or a feature branch, "you must provision an entirely new PostgreSQL cluster and restore from backup or run pg_dump/pg_restore." Zalando's operator and StackGres sit in the same place — both give you strong HA, failover, and point-in-time recovery, and neither gives you copy-on-write cloning. That's not a gap in feature parity; it's a consequence of how they're built. A standard Postgres operator manages a StatefulSet where compute and storage are the same unit — the data directory lives on the volume attached to the running instance. There's no shared, versioned storage layer underneath multiple computes to point a second Postgres process at, so a "branch" can only ever mean "copy the bytes."

Neon's answer starts from a different premise: separate storage from compute entirely, make the storage layer versioned, and let compute processes be disposable pointers into it.

The Three Services a Postgres Operator Doesn't Have​

Neon's storage layer breaks into three pieces, and each one is doing a job no Postgres operator needs:

• Safekeepers durably replicate the write-ahead log. When a compute node commits a transaction, it streams the WAL record to a quorum of safekeepers running a Paxos-like consensus protocol — the transaction is only acknowledged once that quorum agrees, independent of where the data eventually lands.
• Pageservers turn that WAL stream into queryable data. Each pageserver maintains versioned "timeline" objects — effectively a key-value store of pages keyed by log sequence number (LSN) — reconstructing any page as of any point in its history by replaying WAL on top of the last stored image.
• The storage broker coordinates between safekeepers and pageservers so each side knows which nodes hold which timelines.

A branch, in this architecture, is the operation of pointing a new compute process at an existing timeline in the pageserver and letting new writes diverge from there. Nothing terabyte-sized moves. That's the entire trick — and it's also why it can't be retrofitted onto a StatefulSet-based operator without rebuilding the storage layer underneath it.

What Self-Hosting It Actually Requires Today​

The gap used to be total: Neon's storage engine was open source on GitHub, but nobody had packaged it to run outside Neon's own cloud. That changed with neon-operator — a Kubernetes controller, not affiliated with Neon itself, that stands up the full storage stack as native Kubernetes workloads. Reading its own documentation, here's the concrete bar to clear:

That's five extra pieces of infrastructure — an object store, a metadata Postgres instance, and the CRD-driven controller logic to wire them together — before a tenant creates their first branch. Compare that to CNPG, where the entire ask is "give me a StorageClass and a Kubernetes cluster."

And once it's running, the operator's own documentation is direct about where it stops matching managed Neon:

• No automatic compute autoscaling. Managed Neon scales compute to zero when a branch is idle and back up on the next connection; the self-hosted computes "run persistently" instead — you're paying for idle capacity the whole pitch was supposed to eliminate.
• Manual tenant sharding. Splitting a large timeline across pageservers for scale is a configuration task, not an automatic one.
• Performance not yet optimized, in the operator's own words, with day-2 operations still under active development.

The project describes itself as "functional for development and testing environments" — not a hedge, a direct statement of where it's at. That's a genuinely different thing from "doesn't work." It means the architecture runs, branches actually create in the time you'd expect, and a team can kick the tires on real infrastructure today. It also means shipping it as a tenant-facing production feature right now means owning the autoscaling, sharding, and performance work Neon's commercial product has already done.

Once the storage stack is up, creating a branch looks like any other Kubernetes object — which is itself the point: it's a kubectl apply, not a bespoke API call, and that's exactly the shape an AI agent's tool-calling layer already knows how to drive.

kind: NeonBranch
apiVersion: oltp.molnett.org/v1
metadata:
  name: preview-pr-482
spec:
  name: preview-pr-482
  pg_version: "PG17"
  default_branch: false
  project_id: acme-app

That CR — applied after a NeonCluster and a NeonProject already exist — is the entire "branch" operation from the caller's side — no dump, no restore, no second cluster to provision. The work described above (Safekeepers, pageserver timelines, the storage broker) is what makes a short YAML file resolve into an isolated, writable Postgres endpoint in seconds instead of minutes. It's also exactly why that YAML file only works at all once the five pieces of infrastructure in the table above, plus the parent NeonCluster and NeonProject objects, are already running underneath it.

The Databricks Backdrop Doesn't Change the Self-Hosting Math​

Databricks closed its roughly $1 billion acquisition of Neon in mid-2025, and the code didn't go closed-source — neondatabase/neon is still the same open repository the operator above is built against, and Databricks has repeatedly framed openness as core to the deal (Lakebase, its own managed product built on Neon's engine, is pitched explicitly on open formats and open storage). That matters for a self-hosting question in one narrow way: the architecture isn't going to disappear or get relicensed out from under a community operator built on it.

It doesn't matter in the way it might sound like it should. Databricks being "committed to open source" is a statement about the storage engine's license, not a statement about anyone having done the packaging, autoscaling, and operational hardening work to make that engine trivial to run outside Neon's own infrastructure. That work is exactly what neon-operator is doing independently, several steps behind the commercial product, which is the normal shape of an open-core gap — not a sign that Databricks is quietly closing the door.

The Honest Answer for a Tenant Who Wants This​

A platform that treats managed databases as a deliberate non-goal — which is exactly bex's position — doesn't get to bundle Neon-style branching as a checkbox feature, and shouldn't pretend the gap doesn't exist. The honest answer to a tenant asking for it today has two parts, and both are worth saying out loud rather than leaving implicit:

For HA Postgres with backups, failover, and point-in-time recovery, CNPG on a Cluster API-managed fleet is the well-trodden default, and that answer hasn't changed — none of this is an argument against running Postgres yourself for the workload it was always good at.

For instant copy-on-write branching specifically, the honest answer as of mid-2026 is: run neon-operator yourself, on infrastructure you provision (object storage, NVMe volumes, a metadata Postgres instance), and go in expecting development- and testing-grade maturity — not a drop-in replacement for managed Neon's autoscaling and sharding. That's a real, working option today in a way it wasn't a year ago, and it's also not the same claim as "solved."

That distinction — real and available versus production-ready — is the whole difference between a platform that's honest about what self-hosting costs in engineering time, and one that lets a tenant find out the hard way.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Managed databases were never the pitch, and neither is pretending every open-source project is a one-click feature; a Cluster API fleet running CNPG (or, if you need it, neon-operator) on infrastructure you control is. Star the repo on GitHub or deploy your first app today.