SYSTEM Cited by 3 sources
Neon¶
Neon is a serverless, separated-compute-and-storage Postgres database originally developed by Neon Inc. and acquired by Databricks in 2025. Architecturally it is the underlying technology that powers systems/lakebase (the Databricks-branded Postgres-compatible OLTP service); the 2026-04-29 Stripe-Projects ingest established the Neon ≡ Lakebase architectural identity and the 2026-05-27 reliability post canonicalised that "In Lakebase and Neon, all databases, regardless of tier and configuration, are backed by distributed, zone-redundant, highly available storage" — naming both interchangeably.
This page covers Neon as a distinct entity primarily because:
- The reliability post and earlier sources cite Neon-specific operational data (e.g. the 90%-of-sessions-under-10-minutes Neon empirical chart; the neonstatus.com public status page).
- Some Neon-side documentation (notably the autoscaling-architecture page for the in-house vertical-autoscaling virtualisation layer) is the architectural source-of-truth for Lakebase-side claims.
- The acquisition history matters for understanding lineage attributions (Pageserver / Safekeeper / virtualisation layer all originated at Neon pre-acquisition).
Architectural shape¶
The same shape as systems/lakebase:
- Stateless Postgres compute (concepts/stateless-compute): ephemeral VMs that hold no durable state on local disk.
- Zone-redundant storage (concepts/zone-redundant-storage): durable bytes in object storage with multi-AZ NVMe SSD caches.
- Pageserver + Safekeeper: the page-storage and WAL components that externalise durable state out of the compute VM.
- Vertically-autoscaling virtualisation layer: schedules multiple Postgres instances onto bare-metal cloud-instance pool, bypasses cloud-provider VM control plane on the per-Postgres start path. See patterns/preallocated-bare-metal-pool-with-virtualization.
- concepts/scale-to-zero: auto-suspend on idle, auto-resume on connection arrival.
- concepts/database-branching: copy-on-write fork of an existing database state.
Operational signal: Neon session-lifetime distribution¶
The 2026-05-27 reliability post discloses one Neon-specific empirical datum (Source: sources/2026-05-27-databricks-how-the-lakebase-architecture-stays-resilient-to-cloud-failures):
"In Neon, 90% of compute sessions for auto-suspending databases are less than 10 minutes."
This is the load-bearing chart for the "control plane is the new data plane" argument: 90% of sessions are short enough that every connection arrival from an idle client triggers a control-plane database-start, putting the start path on the synchronous request path of the workload.
Public status¶
https://neonstatus.com/ is the customer-facing high-level status surface. The reliability post explicitly notes that "the user-visible status you see at https://neonstatus.com/ is a high-level view" and that internally Lakebase / Neon measure higher-resolution per-database availability attainment across the fleet.
Lineage attributions¶
- Pre-acquisition Neon invented the Pageserver + Safekeeper design and the in-house vertical-autoscaling virtualisation layer.
- Stas Kelvich (Neon co-founder, now on Lakebase) is one of the reliability roadmap authors; his Neon-era contributions include fault-tolerant multi-master replication with quorum commit, cross-node snapshot isolation using loosely synchronized clocks, and improvements to two-phase commit and logical replication (Source: same).
- Postgres Professional (Stas Kelvich's pre-Neon employer) is cited as the formative ground for Postgres-internals expertise.
Seen in¶
-
sources/2026-05-27-databricks-how-the-lakebase-architecture-stays-resilient-to-cloud-failures — canonical Neon reliability-roadmap framing. Names the public status page. Discloses the 90%-of-sessions-under-10-min Neon empirical chart. The "all databases regardless of tier" zone-redundancy verbatim names both Lakebase and Neon interchangeably.
-
sources/2026-04-29-databricks-and-stripe-projects-infrastructure-built-for-agents — established the Neon ≡ Lakebase architectural identity. The <350 ms agent-provisioning latency for a Neon/Lakebase Postgres through Stripe Projects is the first concrete operational datum on the database-startup-time SLI. See concepts/database-startup-time-sli.
-
sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres — Customer-Managed Keys post. Discloses Pageserver + Safekeeper as inherited Neon components and the storage/compute separation that drives the two-tier envelope-encryption + per-boot-ephemeral-key design.
Related¶
- systems/lakebase — the Databricks-branded packaging; same architecture
- systems/postgresql — the Postgres core that Neon extends
- systems/pageserver-safekeeper — the storage-tier Neon components
- concepts/compute-storage-separation — the architectural shape
- concepts/stateless-compute — the compute-tier property
- concepts/zone-redundant-storage — the storage-tier property
- concepts/scale-to-zero — the workload-shape property
- concepts/control-plane-as-the-new-data-plane — the workload-driven reframe; 90%-of-sessions-under-10-min is the empirical datum
- concepts/database-branching — Neon's copy-on-write database fork primitive (extensively covered in Lakebase ingests)
- concepts/agent-provisioned-database — the agentic-workload primitive Neon implements
- companies/databricks — the parent company post-2025