Skip to content

SYSTEM Cited by 5 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 (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. This layer is NeonVM — a QEMU/KVM Kubernetes custom resource + controller that performs in-place CPU/memory resize of a running Postgres VM and can live-migrate it (keeping its IP) when a node is full. See 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

Last updated · 766 distilled / 2,225 read