The same architecture that powers your analytics pipelines is now powering transactional databases
Every data engineer who has worked with the lakehouse understands one core idea: separate compute from storage, use open formats, and let different workloads share the same data.
This idea transformed analytics. It broke the lock-in of proprietary data warehouses. It made it possible to run SQL queries, machine learning, and streaming on the same data without moving it.
Now Databricks is applying that same idea to transactional databases.
They call it Lakebase.
If you understand Delta Lake, you already understand most of what makes Lakebase work. The same principles. The same architecture. Just applied to a problem that has been stuck in the old world for decades.
Think about a traditional database like MySQL or PostgreSQL.
Compute and storage are tightly coupled. Your database server holds both the processing engine and the data files. If you need more storage, you often need to scale the whole server. If you need more compute for a heavy query, same thing.
This coupling creates real problems at scale:
Sound familiar? These are the exact problems data engineers solved for analytics years ago when the lakehouse architecture emerged.
The Delta Lake chapter explains how open storage formats solved the lock-in and reliability problems that plagued earlier analytics architectures.
To understand Lakebase, it helps to see where databases have been.
flowchart LR
A["Generation 1\nMonolith\nMySQL, PostgreSQL"] --> B["Generation 2\nProprietary Decoupling\nAurora, AlloyDB"]
B --> C["Generation 3\nLakebase\nOpen Storage on the Lake"]
style A fill:#f59e0b,color:#000
style B fill:#3b82f6,color:#fff
style C fill:#10b981,color:#fffGeneration 1: The Monolith. MySQL, PostgreSQL, Oracle. Compute and storage on the same machine. Simple to start, painful to scale. Your data is locked in the engine's proprietary format.
Generation 2: Proprietary Decoupling. Amazon Aurora and Google AlloyDB separate compute from storage, but the storage layer is still proprietary. You get elastic compute, but your data is still locked into one vendor's format. You still cannot query it from your lakehouse without ETL.
Generation 3: Lakebase. Compute and storage are fully separated. Storage uses open formats on the data lake. The same data that powers your transactional application can be queried directly by your analytics engine. No ETL required. Lakebase is now generally available and includes Private Link support.
Lakebase is not just "a database on the cloud." It is a specific architectural pattern with five defining characteristics.
The database engine runs as a serverless compute layer. The data lives in cloud object storage. You can scale compute independently of storage, and you only pay for what you use.
This is exactly how the lakehouse handles analytics workloads. The same principle, applied to OLTP.
Databricks chose PostgreSQL as the SQL interface for Lakebase. This matters because Postgres is the most widely adopted open-source database. Applications already know how to talk to it. ORMs, connection pools, drivers, they all work.
You do not need to rewrite your application to use Lakebase. You point your Postgres connection string at it and go.
This is the breakthrough. Traditional databases store data in proprietary page formats that only their engine can read. Lakebase stores data in open formats on the lake.
This means your analytics engine can read the same data directly. No CDC pipelines. No nightly ETL jobs. No stale copies. Native Lakehouse Sync (Public Preview) can also replicate Lakebase Postgres into Unity Catalog managed tables automatically.
The dream that data engineers have been chasing for years: one copy of the data that serves both transactional and analytical workloads.
Your application writes orders to a table. Your analytics dashboard reads from the same table. No delay. No synchronization lag. No dual-maintenance.
This is where Lakebase gets interesting for development workflows. You can branch a petabyte database in seconds. Create an isolated copy for testing. Run migrations against it. Merge changes back.
This is Git for databases. The same workflow developers use for code, applied to data.
If you have been reading BricksNotes, you already know most of the concepts Lakebase relies on. The vocabulary is the same.
| Lakehouse Concept | Lakebase Equivalent | BricksNotes Chapter |
|---|---|---|
| Delta Lake open storage | Open-format database storage | Delta Lake |
| Unity Catalog governance | Same catalog governs both | Unity Catalog |
| Medallion Architecture | Lakebase feeds directly into gold | Medallion |
| Structured Streaming | Real-time OLTP to analytics | Streaming |
| Schema Evolution | Database schema changes without downtime | Schema Evolution |
| Compute-storage separation | Same principle for OLTP | Partitioning |
| Data quality expectations | Validation at the source | Data Quality |
The key insight is that Unity Catalog governs both your lakehouse tables and your Lakebase tables. One governance layer. One set of permissions. One lineage graph.
The Unity Catalog chapter explains how the three-level namespace works and why centralized governance matters for exactly this kind of cross-engine architecture.
To appreciate what Lakebase changes, think about what a typical data engineering pipeline looks like today when application data needs to reach the lakehouse.
flowchart TD
A[Application Database] --> B[CDC Tool]
B --> C[Streaming Ingestion]
C --> D[Bronze Layer]
D --> E[Silver Layer]
E --> F[Gold Layer]
F --> G[Dashboard / Analytics]
style A fill:#f59e0b,color:#000
style B fill:#ef4444,color:#fff
style C fill:#ef4444,color:#fff
style D fill:#3b82f6,color:#fff
style E fill:#3b82f6,color:#fff
style F fill:#10b981,color:#fff
style G fill:#10b981,color:#fffYou need a CDC tool (Debezium, Fivetran, etc.), a streaming ingestion layer, and multiple medallion layers before the data is ready for analytics.
With Lakebase, the first three steps disappear. The application database already stores data in open formats on the lake. Your analytics engine reads it directly.
flowchart TD
A[Lakebase] --> F[Gold Layer / Analytics]
A --> G[ML / AI Workloads]
style A fill:#10b981,color:#fff
style F fill:#10b981,color:#fff
style G fill:#10b981,color:#fffThis does not mean the medallion architecture disappears entirely. You may still want curated gold tables for complex business logic. But the mechanical work of getting data from point A to point B is dramatically reduced.
The Data Sources chapter covers the various ways data enters the lakehouse. Lakebase adds a new, simpler path.
One of Lakebase's most innovative features is database branching.
Imagine you need to add a column to a production table. Today, that involves careful migration scripts, testing in a staging environment that may not have production-scale data, and hoping nothing breaks.
With Lakebase:
This is the same workflow that made Git transformative for software development. Applied to databases.
For AI agent workflows, this is especially powerful. An AI agent can spin up an isolated database branch, experiment with schema changes or data transformations, validate results, and merge back. All without touching production.
The Incremental Processing chapter explains the copy-on-write patterns that make this kind of branching possible at scale.
Lakebase has direct cost implications for data engineering teams.
The most obvious saving is eliminating CDC infrastructure. If your application database stores data in open formats on the lake, you do not need Debezium, Fivetran, or custom CDC pipelines to get that data into your lakehouse. That is one less tool to manage, one less pipeline to monitor, and one less point of failure.
Serverless compute means you do not pay for idle database capacity. Traditional databases require you to size for peak load. Lakebase scales down to zero when your application is quiet.
Open storage means no egress fees for analytics. Your lakehouse queries read from the same storage layer. No data movement, no transfer costs. OpenSharing (the evolution of Delta Sharing) further simplifies this by providing an open protocol for sharing these assets across platforms.
The Cost-Efficient Pipelines article covers optimization strategies that become even more impactful when combined with Lakebase's architecture.
If you are a data engineer, Lakebase does not make your skills less relevant. It makes them more relevant.
The companies adopting Lakebase still need people who understand:
These are the same skills you have been building. Lakebase just removes the mechanical plumbing work and lets you focus on the architecture and logic that actually matters.
The boundary between "application database" and "data lake" is dissolving. Engineers who understand both sides will be the most valuable.
The Workflows chapter and Unit Testing chapter cover the orchestration and validation patterns that remain essential regardless of where the data originates.
Lakebase is part of a broader trend at Databricks. The Agentic Enterprise vision requires data to be accessible, governed, and trustworthy. Lakebase brings application data into that vision.
Agent Bricks shows how AI agents can work across both analytical and transactional data. Lakewatch demonstrates how security operations benefit from the same unified architecture.
The Small File Problem and performance optimization patterns you have learned for the lakehouse apply directly to Lakebase's open storage layer.
Every architectural pattern you have studied in this guide, from Delta Lake transactions to Unity Catalog governance to medallion architecture, is a building block for this converged future.
The lakehouse was the first step. Lakebase is the next.
The complete BricksNotes guide covers 21 chapters of data engineering fundamentals that directly apply to Lakebase architecture. Read the first 3 chapters free.