Lakebase architecture delivers faster Postgres writes

>Without those periodic full page images in the log, the storage layer would have to replay an infinitely long chain of small deltas to reconstruct a page for a read request. What was once a bounded O(checkpoint frequency) replay becomes an unbounded chain, leading to a spike in read latency and resource consumption.

I don't follow: read requests are not served from the WAL. They read the current state of the page from the buffer cache, where the page is updated after the change (FPI or not) is written to the WAL.

How does Lakebase compare to OrioleDB[0]?

[0] https://www.orioledb.com/

So, the general architecture described here is solid, and I support it, but I take issue with the "Lakebase" naming thing.

Disaggregated storage and disaggregated compute have been an open trend in DBMS development for the last half-decade. This is an obvious move with modern computing paradigms, and the academic literature has a standard name for it.

This feels like "JAMStack" from Netlify happening all over again.

I tweeted about this in 2022, as a general trend, and also from the RocksDB meetup emphasizing disaggregated storage:

- https://x.com/GavinRayDev/status/1607769112234823680

- https://x.com/GavinRayDev/status/1600666127025156096

How does Lakebase compare to Ducklake[0]?

[0] https://ducklake.select/

I'm a VP on Databricks and former CEO of Neon. Happy to answer performance related or any other questions here.

Im not a proper DBA, but oversee some basic postgres installs (read: logging, monitoring, upgrades).

This appears to only have any effect with datalake style installs, where storage is separate from compute.

Not going to have any effect on those small postgres installs for that generic one off app.

[dead]