Object Storage + WAL: Lakebase Postgres for the agentic era

Summary

The post presents Lakebase Postgres as a design for agent workloads that need isolated copies, restores, replicas, historical queries, and many short-lived databases without repeatedly moving large datasets. It contrasts conventional data-centric OLTP with a transaction-centric model in which PostgreSQL’s write-ahead log (WAL) is the source of truth, with LSNs making database history addressable. Lakebase splits compute, which runs standard Postgres and uses RAM and local NVMe caches, from storage, where safekeepers replicate WAL through quorum acknowledgements, a pageserver materializes pages, and object storage retains immutable history. Commits wait for replicated WAL acknowledgement, not page uploads, while reads request pages at an LSN. The design supports point-in-time queries, cheap branch or read-only compute, scale-to-zero suspension, and shared transactional and analytical access, while still relying on RAM and NVMe for performance.

Context

Agent workloads often request isolated copies of production, reversions to earlier statements, historical table states, and many concurrent temporary databases. In conventional OLTP, copies and backups require moving large volumes of data, making these operations slow and expensive.

Approach / What changed

Lakebase Postgres makes the WAL-backed transaction timeline the durable source of truth and treats data files as derived, cached representations. Standard Postgres runs on an independently scalable compute layer, while safekeepers replicate WAL using quorum acknowledgement, the pageserver materializes requested page versions, and object storage retains immutable history. Reads identify the required page and LSN; compute can start, stop, or scale independently of durable state.

Takeaways

• A transaction commits after a quorum of safekeepers acknowledges its WAL record; page materialization and object-storage upload occur afterward, outside the transaction’s critical path.
• GetPage@LSN lets the storage layer return a page as it existed at a specified LSN, supporting direct historical queries and comparison without first restoring a database.
• Read-only compute nodes request pages from the shared storage layer rather than maintaining data copies, while idle compute can suspend after five minutes and reactivate within a few hundred milliseconds.

Related reading