Postgres, with storage and compute pulled apart.
A warehouse is built for scanning years of history. An application updating the same row four hundred times a minute wants something else entirely, which is why every analytics platform eventually acquires a transactional database beside it and a pipeline between them to maintain. Lakebase is Databricks’ version of that database: open-source Postgres, not a fork, with its storage in open formats on object storage and a serverless engine over the top that branches like code and scales to zero.
No new dialect to learn, no driver to wait for.
This is the claim to check first with any managed database, because “Postgres-compatible” has meant a dozen different things over the years. Databricks is explicit: Lakebase runs open-source Postgres, not a fork and not a new SQL dialect.
Standard clients, drivers and ORMs work. psql, pgAdmin and DBeaver connect. Most popular extensions are supported, PostGIS and pgvector among them — which is how vector, keyword and hybrid search happen inside the database rather than in a separate service you have to keep in step.
The practical consequence is that your existing application code, your migrations, your connection pooler and your developers’ habits all transfer. The novelty is entirely underneath.
Open formats on object storage
Data lives in open formats on low-cost cloud object storage rather than on attached disks.
A serverless Postgres engine
Scales elastically with the workload, and separately from the storage beneath it.
Scaled to zero
No spend on capacity nobody is using, which changes what is affordable to keep running.
One primary, up to three secondaries
Across availability zones, with failover and reads offloaded onto the secondaries.
The feature that changes how your team works.
Separating storage from compute makes something possible that is genuinely new to most teams: a database branch, taken instantly, holding production-shaped data, that can be worked against and then thrown away.
A staging box and a nightly dump
Somebody maintains a restore script. The staging data is a week old, anonymised badly, and three times a year the restore fails silently. Nobody tests against real data because real data is awkward to get.
A branch, in a moment
Take a branch, work against production-shaped data, reset it when it drifts, discard it when done. The live workload is untouched throughout.
Validate the restore first
A restore can be checked on an isolated branch before it reaches production — which turns the most frightening operation in database administration into something you can look at before committing to.
The sync pipeline you are maintaining today.
Here is the shape almost every estate has. An application database holds the live state. A nightly or hourly job copies it into the warehouse so it can be reported on. A second job copies curated results back out so the application can use them. Both jobs are owned by someone who did not write them, and the two sides are permanently a little out of step.
Databricks calls running transactional and analytical work over one governed copy LTAP — lake transactional and analytical processing. Transactions and analytics read the same data, so the sync in the middle stops existing, and the Lakebase Change Data Feed carries transactional change into the lakehouse without an ETL step.
The honest framing: this does not abolish the difference between the two workloads, it just means you are not also maintaining the plumbing between them. The row store and the columnar files are still different shapes for different jobs — and that is fine, because that part was never the problem.
Two systems, two jobs, one lag
- An extract job out of the application database.
- A load job back in with the curated results.
- Two permission models to keep aligned.
- A lag everyone has learned to work around.
- A reconciliation nobody runs.
One copy, governed once
- Transactional and analytical reads over the same governed data.
- A change feed into the lakehouse with no pipeline in between.
- Unity Catalog permissions covering both paths.
- No lag to explain to the business.
- One fewer job for somebody to inherit.
What Databricks states, and what to read.
For a database holding live application state, the published commitments matter more than the feature list. These are the ones Databricks states.
An SLA is a number and a remedy
Four nines sounds like 52 minutes a year, and it may be. What matters as much is what the agreement covers, what it excludes, what the measurement window is, and what it actually pays when missed — which is usually service credits rather than your losses.
We read that document as part of an architecture review rather than after an outage, and we tell you plainly whether your application’s availability requirement is met by the platform or needs designing for on top of it. The compliance wording — “supported… limited” — deserves the same treatment if you are in a regulated sector.
Databricks publishes no latency benchmark for Lakebase, and its scale claim is the memorable but unquantified “from 1 row to 1 billion vectors”. If your application has a latency requirement, that is a thing to measure in a pilot, not a thing to assume from a product page — ours included.
Four jobs, in the order people reach them.
These are the use cases Databricks names, arranged by how we actually see teams arrive at them.
The database behind an internal application
Usually the first one, because it arrives with a Databricks App: a tool that reads governed data, writes back decisions, and needs somewhere to keep them. Serverless, scaling to zero between uses, with no server to request. Databricks Apps →
State and memory for agents
Agent sessions and long-term memory are stored in Lakebase-backed stores. This is why an agent can remember what it was told last week rather than re-asking, and it is the difference between a novelty and something people rely on. Agent Bricks →
Vector, keyword and hybrid search in one place
With pgvector inside the same Postgres, a retrieval query can combine semantic similarity with ordinary filters — “items like this description, with under seven days of cover, in the Western region” — in one statement, against one database, under one set of permissions.
Operational analytics and planning
Reading analytical data without an ETL hop, which is what makes an inventory or replenishment screen both current and correct. Databricks names inventory intelligence and planning specifically.
What usually arrives with it.
A database on its own is not a project. These are what it is normally part of.
Databricks Apps
Streamlit, Dash and Gradio apps on serverless compute, with sign-in, permissions and Unity Catalog around them instead of a server you have to ask IT for.
Read it →Artificial intelligenceAgent Bricks
A runtime for agents that survive a crash, memory and sessions, tools and MCP servers, search over your documents, traced runs and evaluation by judges and by your experts.
Read it →Data warehousingLakehouse
SQL analytics on Delta Lake and Apache Iceberg tables in your own cloud storage, with serverless compute, self-tuning layouts and a real-time tier for dashboards and apps.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What people ask about the database.
Is this real Postgres, or a lookalike?
Open-source Postgres, not a fork and not a new dialect. Standard clients, drivers and ORMs work; psql, pgAdmin and DBeaver connect; and most popular extensions are supported, including PostGIS and pgvector.
What is different is underneath: data lives in open formats on cheap object storage with a serverless Postgres engine over it, so compute scales — and scales to zero — separately from storage.
What does branching a database mean in practice?
You take an instant branch for development or a test, work against production-shaped data, and reset it without touching the live workload. A restore can be validated on an isolated branch before anything reaches production.
Anyone who has restored a dump into a staging box overnight will recognise what that removes. It makes "test with real data" a normal Tuesday rather than a project.
Why not just use the lakehouse tables?
Because transactional reads and writes are a different shape of work from analytical scans. An application or an agent updating a row thousands of times a minute wants a row store with Postgres semantics; a query scanning three years of history wants columnar files.
Databricks calls running both over one governed copy LTAP, and the Lakebase Change Data Feed moves transactional data into the lakehouse without a pipeline in between. The point is to stop building and babysitting that sync yourself.
Is it reliable enough for a production application?
Databricks publishes a 99.99% uptime SLA for production apps, with a primary read-write instance paired with one to three secondaries across availability zones, failover, and read offloading onto the secondaries. On compliance it states SOC 2 and HIPAA, with PCI-DSS and HITRUST support on Azure and AWS, described as limited.
As with any SLA, read what it covers and what it pays. We do that reading as part of an architecture review rather than after an outage.
What would we use it for first?
The use cases Databricks names are the honest ones: state and long-term memory for agents, vector, keyword and hybrid search inside Postgres, operational analytics without an ETL hop, and planning applications such as inventory intelligence. Its scale claim is "from 1 row to 1 billion vectors"; it publishes no latency benchmark.
In a typical first project it is the database behind one internal application that needs to read governed data and write back decisions — which is also exactly what Databricks Apps is for.
Tell us about the sync job nobody owns.
Most estates have one: a job copying between the application database and the warehouse, written years ago, feared by everyone. We will map what it moves, whether a change feed replaces it, and what your application's latency and availability requirements actually need — including when the answer is that your current database is fine.
- Your Postgres code and ORM, unchanged
- Branches instead of a staging restore
- The sync pipeline mapped and costed
- The SLA read before it is relied on
- Latency measured, not assumed
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
The Ashgate Rule is our shorthand for looking after the details nobody sees in Databricks Lakebase.