Skip to content

SYSTEM Cited by 1 source

Pageserver + Safekeeper (Lakebase / Neon storage tier)

Pageserver and Safekeeper are the two server components of the Neon-lineage Postgres storage tier — the durable, long-lived storage layer that sits underneath ephemeral Postgres compute VMs in a separated-compute-and-storage managed-Postgres architecture. systems/lakebase inherits them from Neon (acquired by Databricks in 2025).

They are the "storage side" half of the concepts/compute-storage-separation split that makes scale-to-zero Postgres compute feasible.

What each does

  • Pageserver. Owns page-level durable state. Answers "give me the contents of page P of relation R at LSN L" against its own object-storage-backed data + local caches. Compacts and organises WAL into a page-addressable form so that newly-booted compute instances can materialise any page on demand without replaying the whole log. Effectively the durable page store + read-side cache tier.
  • Safekeeper. Owns the durable WAL (Write-Ahead Log). Postgres compute writes WAL segments to the Safekeeper; the Safekeeper is responsible for persisting them before acknowledging the commit. Typically run as a replicated group to tolerate node failures at commit time. Segments eventually flow downstream to the Pageserver for compaction into page-addressable form, and to long-term object storage.

Together they externalise both the page heap and the WAL out of the Postgres compute VM, so the compute VM holds only buffer pool, connection state, query plans, and other scratch — and can therefore scale to zero.

Ingested-source references

The only source in the corpus naming both components so far is the Lakebase CMK launch:

The storage layer (Pageserver and Safekeeper) maintains long-lived, persistent data in object storage and local caches, while the compute layer runs independent Postgres instances that scale up, down, or to zero based on demand.

(Source: sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres)

That post also positions both components as being under the same concepts/envelope-encryption hierarchy — all data segments managed by Lakebase, including WAL segments stored by Safekeeper and data files stored by Pageserver, are encrypted with DEKs wrapped by KEKs under the customer's CMK.

Why the split matters

  • Compute scale-to-zero. Durable state does not live on the compute VM; a VM can be terminated and re-created without data loss. Cold start becomes a matter of re-attaching to Pageserver / Safekeeper, not rebuilding state from scratch. See concepts/stateless-compute.
  • Independent scaling axes. Storage (capacity + durability) and compute (CPU + memory) scale on separate curves, like Snowflake and Aurora DSQL at different layers. See concepts/compute-storage-separation.
  • Replication / HA reshaped. Safekeeper handles commit-time durability; read HA is absorbed into Pageserver replicas + object- storage. Compute HA is "just start another VM", because there's no compute-local durable state to replicate.
  • Encryption boundary is clean. The storage tier encrypts everything under DEKs wrapped by the envelope hierarchy; the compute tier deals separately with scratch plaintext via patterns/per-boot-ephemeral-key.

Caveats

  • Ingested-source coverage is still thin: we know these components exist inside Lakebase and that they sit under the CMK envelope, but we don't have a Databricks or Neon engineering deep-dive ingested yet. Commit latency, failover, compaction cadence, and replication-factor configurability are not described here.
  • Lineage note: the naming "Pageserver / Safekeeper" comes from Neon's open-source architecture and is adopted by Lakebase; the Neon acquisition itself was previously logged as a skipped PR announcement (2026-04-21 log entry).

Seen in

  • systems/lakebase — the managed-Postgres service that consumes these components.
  • systems/postgresql — the upstream DB engine they externalise storage for.
  • systems/aurora-dsql — a different structural answer to the same "separate Postgres state from compute" problem (Aurora DSQL swaps individual Postgres subsystems via extensions; Neon-lineage Pageserver+Safekeeper pulls the whole page/WAL tier out).
  • concepts/compute-storage-separation — the architectural principle this realises for Postgres.
  • concepts/envelope-encryption — the encryption model covering both components.
Last updated · 200 distilled / 1,178 read