A calm, engineer-to-engineer read on where Lakebase fits, when to keep the Postgres you have, and how to think about operational and analytical systems as one.
Every few months, a familiar conversation comes back.
The app team wants a Postgres. Something small, something fast, something that can serve the product without waiting on the warehouse. You already run a lakehouse. You already have Delta, Unity Catalog, jobs, dashboards. And now the question lands on your desk again.
Do we spin up another database?
With Lakebase now generally available, this is worth thinking about slowly. Not because the answer is always yes, and not because the answer is always no. It depends on what your systems are actually for.
Lakebase is a Postgres-compatible database that lives inside Databricks. It speaks the Postgres wire protocol, so your app can connect to it the same way it would connect to any other Postgres. It is serverless. It supports branching, so you can create a working copy of your data for a feature or a test, then throw it away.
The part that matters for data engineers is the connection to Unity Catalog. Tables in Lakebase can be synced with tables in the lakehouse. That means the same governance that covers your bronze, silver, and gold layers can also cover the Postgres your app talks to. No shadow copies. No parallel access model.
So Lakebase is not a warehouse. It is not a lake. It is the operational database that sits next to them, inside the same platform, under the same catalog.
Before you move anything, ask three questions.
Does my app need single-digit millisecond reads? Lakebase is fast. It is not magic. If your service level requires two milliseconds at the ninety-ninth percentile from a cache-warm node in the same region as your app, measure it. Do not assume. A hosted database in another cloud can be a poor fit for a latency-sensitive service, even a good one.
Do I need real OLTP transactions, or do I just need fast reads? Some teams reach for Postgres when what they really want is a fast, filterable serving layer. If your writes are batched, and your reads are the hot path, a serving table in Delta with the right layout may be enough. If your app really does many small transactions per second, you want a real transactional store. Lakebase is that store. A materialized view is not.
What is my ecosystem? Postgres has a large and old ecosystem. Extensions, drivers, ORMs, migration tools, hosted read replicas, connection poolers. Lakebase covers the common cases well, but if your team depends on a specific extension or a specific operator, check that first. It is easier to check now than to discover later.
Lakebase is a strong choice when your app already lives inside the Databricks story. You already govern data with Unity Catalog. You already run pipelines that produce the tables the app needs to read. You already share models and features across teams.
In that setup, a separate Postgres is a second source of truth. It drifts. It has its own users, its own permissions, its own backup story. Every extra system is a place where the wrong number can appear.
Lakebase removes that seam. The same table that powers the dashboard can also serve the app, through the same catalog, with the same lineage. That is a real simplification for teams who are tired of writing yet another sync job.
A dedicated Postgres still wins in a few cases.
If your app is completely outside the Databricks platform, and it has no reason to be inside, then adding Lakebase adds a dependency for no gain. Keep the Postgres you have.
If your app relies on specific Postgres extensions that Lakebase does not offer, keep the Postgres you have.
If your workload is small, cheap, and stable, and moving it would cost more than it would save, keep the Postgres you have.
The point is not to move everything. The point is to stop building a second data platform just because the first one used to only serve analytics.
Here is a way to think about it that has held up well.
Every data team runs three kinds of systems.
For years, these three systems lived in three different worlds. A Postgres for record. A warehouse for insight. Another Postgres, or a key-value store, for action.
Lakebase does not remove the three systems. It puts them inside one platform, under one catalog, with one access model. That is the shift worth understanding. Not "one database to rule them all", but "one place to reason about all of them".
If you are a data engineer, three habits change gently.
Schemas become one conversation. When the same table can back the app and the dashboard, the schema is not just an analytics decision. Bring the app team in earlier. It saves both sides pain later.
CDC becomes shorter. If the operational store is already in your catalog, the change stream from the record system to the analytical layer is a shorter hop. Fewer connectors. Fewer failure modes.
Reverse ETL becomes rarer. Half of the reverse ETL pipelines that exist today are there to move a score from a warehouse back into a Postgres that the app can read. If both sides live in the same platform, that job may not need to exist at all.
None of this happens overnight. Old systems stay. New systems arrive next to them. That is normal. The work is deciding, honestly, which new system is worth the switch, and which old system is worth keeping.
Lakebase being generally available does not mean everyone needs to migrate. It means the choice is now a real one.
If your app already lives with Databricks, and you are tired of the seam between operational and analytical, Lakebase is worth a serious look.
If your app lives somewhere else and works well, keep it there, and use Lakebase for the next system you build, not the one you already have.
The best data platforms are the ones with fewer moving parts, not more.
If you are thinking about how AI agents change any of this, our companion piece, Your AI is Ready. Is Your Data Foundation?, is a good next read.