Storing · Chapter 10

Lakebase

Lakebase is the part of the platform most often dismissed before it is understood, usually in one sentence: it is just Postgres, and we already have Postgres. That sentence is wrong in a way worth taking apart carefully, because the thing it misses is the thing that changes how teams work.

What people think they are comparing #

The dismissal usually compares a feature list, and on a feature list it looks like a tie.

If that were the whole comparison, the objection would be correct and you should keep your RDS instance. It is not the whole comparison, and the rest of it is not a longer feature list, it is a different architecture.

Separated storage and compute, and what falls out of it #

In a traditional managed Postgres, the storage is attached to the instance. That single fact is the origin of most operational pain: copying a database means physically copying bytes, scaling compute means resizing the thing the data lives on, and restoring means writing a backup back onto disk before anything can query it.

Lakebase separates them. Compute is an ephemeral thing you point at storage, and storage is a versioned, copy-on-write log rather than a disk image.

Once storage is versioned and copy-on-write, a branch is a pointer. Creating one writes almost nothing, because the new branch shares every page with its parent until something changes it, and only the changed pages consume space. This is the same reason a git branch is instant while copying a directory is not.

Branching, in the ways teams actually use it #

This is the capability that has no equivalent on RDS, Azure Database for PostgreSQL, or Cloud SQL. Those services offer snapshots and restores, which sound similar and are operationally nothing like it: a snapshot restore provisions a new instance and rehydrates storage, taking minutes to hours depending on size, and costs a full second copy of the data for as long as it exists.

Every developer gets production data. Instead of a shared staging database that three people are fighting over, or a seed script that generates fake data which never contains the case that breaks production, each engineer branches production and works against real data. When they are done, the branch is deleted.

Every pull request tests against real data. CI creates a branch, runs the migration and the test suite against it, reports, and destroys it. This turns "we think this migration is safe" into evidence, and it catches the class of bug that only appears against real distributions: the migration that is instant on ten thousand rows and locks the table for nine minutes on forty million.

A bad deploy is undone in seconds. If a migration or a bad write corrupts data, you do not restore a backup. You branch from a point in time before the incident and repoint the application. The recovery is measured in seconds, and the corrupted branch is still there to investigate afterwards, which matters because a traditional restore destroys the evidence you need for the post-mortem.

Experiments stop being scary. Trying an index strategy, a schema change, or a bulk correction against a branch of production removes the reason people avoid trying things.

The second thing it does that RDS cannot #

Branching is the headline, and the structural advantage is quieter.

Your operational database and your analytical estate are inside the same governance boundary. The same Unity Catalog model that decides who can read a gold table decides who can read the operational one, and the synchronisation between them is part of the platform rather than a pipeline you built.

On the traditional clouds this is where a real amount of work lives. Getting RDS data into your analytical layer means DMS, or Glue, or a Datastream pipeline, each with its own failure modes, its own IAM configuration, its own monitoring, and its own bill. And the resulting analytical copy is governed by a different system than the source, so "who can see this customer's data" has two different answers that have to be kept in agreement by hand.

Where we reach for it #

Three patterns come up repeatedly in our work, and they are the ones worth trying first.

Decision and evidence logs. The governed action pipeline in Governed Actions writes one record per policy evaluation, one row at a time, at whatever rate the business generates decisions. That is a textbook operational write pattern and a poor analytical one. Writing them to Lakebase and syncing to the lakehouse gives you the low-latency write and the queryable history without building anything between them.

Feature and reference lookup at request time. A model behind an endpoint often needs features computed in batch. Serving them from Lakebase, fed from gold, keeps the latency budget intact without standing up separate feature infrastructure with its own credentials and its own security review.

Application state for data-adjacent tools. Review queues, annotation interfaces, and approval workflows need ordinary transactional storage. Keeping that inside the same account and identity boundary avoids adding another managed database to the estate.

What to be careful about #

We would rather you hear the caveats from us than find them yourself.

It is Postgres-compatible rather than being your existing Postgres. Specific extensions, version behaviours, and the operational tooling you rely on may or may not be present, so migrating an existing database is a real assessment rather than a change of connection string.

The synchronisation with the lakehouse is a moving part with its own latency and failure modes. Treat it as a pipeline that needs monitoring, and decide per dataset which side is authoritative.

Cost accrues continuously the way a database does rather than per query the way a warehouse does. That is not worse, but it does surprise teams who have learned to think about spend in terms of cluster uptime.

How to evaluate it honestly #

If your team is resisting, do not run a feature comparison, because we have already shown you that a feature comparison is a tie. Run this instead, and it takes an afternoon.

Take the largest database you would want to branch. Time how long a snapshot and restore takes on your current platform, and what the restored instance costs per month. Then branch the same data on Lakebase and time it. Then ask your engineers what they would do differently if that operation took one second and cost nothing, and whether the things they listed are things they currently avoid.

The answer to that last question is the whole business case, and it is not on any feature list.

Table of Contents