Can a single database architecture satisfy both vibe-coded and large scale enterprise apps?
The same approach makes small database ultra cheap to run and branch can also make a large one faster and easier to operate. We call this architecture Lakebase.
Oct 19, 2026 · 1:59 AM UTC
9
235
383
16,809
With compute separated from versioned storage, a small app can scale to zero and an agent can branch without copying data.
A large app can add read replicas or replace compute without moving terabytes as well as leverage unbounded iops. These are the consequences of the same design.
1
1
19
2,004
When we started Neon, OLTP on object storage was controversial. People looked at S3 latency and concluded the database would be slow. That would be true if every transaction had to wait for S3.
Now Microsoft's HorizonDB and MongoDB's Atlas Infinite follow essentially the same blueprint: low latency storage tier in front of an object store. I take that as a pretty strong endorsement of the architecture.
1
15
1,813
The same design makes a large-scale application faster. Our durable storage doesn't overwrite pages in place, so we could turn off full-page writes and materialize pages in distributed storage. In HammerDB tests, we saw up to 5x throughput and 94% less WAL.
1
11
1,060
As an app grows, it needs transactions and analytics on the same data. LTAP (Lake Transactional/Analytical Processing) lets Postgres and analytical engines share one logical dataset, with separate compute and no CDC pipeline between them.
1
10
890
The storage layer converts older Postgres data into columnar form exposed through Iceberg. Analytics combines it with recent changes from pageservers to read a consistent snapshot. Postgres supplies the snapshot boundary; the analytical engine serves the scan.
1
10
803
For bulk loads, we already have Spark building Postgres heap pages and indexes outside the primary. It writes them to shared storage, and the primary atomically publishes the result with a compact WAL record. The data never has to pass through the application writer.
1
10
736
The opportunity goes beyond an analytics endpoint. Shared storage also opens a path to offloading index builds, VACUUM and other long-running operations. Preserving MVCC and coordinating concurrent writes and catalog changes is where much of the work remains.
1
11
849
