Why we recommend Databricks Lakebase for OLTP workloads

Most data platforms are designed primarily for analytics. They are excellent at processing large volumes of data, training models, and answering complex questions, but they are not the right place to handle the small, frequent transactions that power an application.

That is the role of an Online Transaction Processing (OLTP) database. It stores the current state of the business: orders, tasks, conversations, approvals, user preferences, and every other record an application needs to read and update with low latency.

Historically, using Databricks for analytics meant choosing and operating a separate database platform for these workloads. Databricks Lakebase changes that equation. Lakebase is a fully managed Postgres database built into the Databricks Data Intelligence Platform, and it has quickly become our preferred OLTP choice for applications already living in the Databricks ecosystem.

Here are the four reasons we recommend it so highly.

1. One place to manage your data platform

The first advantage is refreshingly simple: Lakebase lives inside Databricks.

You access Lakebase from the same Databricks workspace used for notebooks, SQL warehouses, jobs, models, applications, and Unity Catalog. Projects, database branches, compute, the SQL editor, and tables are all available without moving to a separate cloud console or signing into another database service.

That proximity matters more than it may sound. A separate database normally brings another management interface, another identity boundary, another permissions model to coordinate, and another operational surface for the team to learn. Lakebase does not eliminate the need to manage Postgres roles and database permissions, but it brings the day-to-day experience into the platform where the rest of the data work already happens.

The result is less friction for developers and a much clearer view of the organization’s data assets. Lakebase databases can also be registered in Unity Catalog, allowing teams to discover and govern operational data alongside their lakehouse data.

2. Lakehouse-to-Lakebase sync takes about a minute to configure

One of the most compelling Lakebase features is how easily lakehouse data can be made available to an operational application.

With synced tables, a Unity Catalog table can be copied into Lakebase as a Postgres table. In practice, configuring that sync through the Databricks interface can take about a minute: select the source, choose the Lakebase destination, and choose a sync mode.

This is effectively managed reverse ETL. Customer profiles, product recommendations, risk scores, forecasts, and other data products created in the lakehouse can be served from Postgres with the low-latency access pattern an application expects. Continuous mode keeps incremental changes close to the source, while triggered and snapshot modes provide different freshness and cost tradeoffs.

The distinction between setup time and data movement is important. A small table may become available quickly, while the initial copy of a large dataset will naturally take longer. The significant benefit is that the integration does not require a custom synchronization service, a hand-built pipeline, or another vendor.

The reverse direction is supported too, using a different mechanism. Lakebase Change Data Feed captures changes made in Postgres and stores them as Delta history tables in Unity Catalog. Together, synced tables and Change Data Feed create a practical bridge between analytical and operational data without pretending that the two workloads are the same.

3. Query Lakebase and lakehouse data together

Moving data is not always necessary. After a Lakebase database is registered in Unity Catalog, Databricks SQL can query its Postgres tables alongside Delta tables in a single statement.

For example, an analyst could join the current status of orders in Lakebase to customer segments calculated in the lakehouse:

SELECT
    o.order_id,
    o.status,
    c.customer_segment,
    c.predicted_lifetime_value
FROM lakebase_operations.public.orders AS o
JOIN main.customer_analytics.customer_profiles AS c
    ON o.customer_id = c.customer_id;

This removes a familiar data-engineering delay. Teams can answer questions that cross the transactional and analytical worlds without first designing an ingestion pipeline merely to make the data queryable.

The registered Lakebase catalog is read-only and currently requires a Serverless SQL Warehouse. Application writes still go through Postgres directly, while the federated catalog provides safe access for analytics, dashboards, and exploration.

4. A natural database for agentic workflows

Agents do more than answer questions. Useful agents remember context, maintain state, create tasks, update records, request approvals, and trigger the next step in a business process. Those actions require a transactional system of record, not just a vector index or a collection of files.

Lakebase provides that system of record using standard Postgres. Databricks explicitly supports Lakebase as a store for agent state and memory, including agents deployed through Databricks Apps and Model Serving.

The more interesting pattern is what happens after an agent writes. The Lakebase Change Data Feed captures every insert, update, and delete from the Postgres write-ahead log and writes those changes into Unity Catalog as managed Delta history tables. Databricks currently documents changes as being flushed in batches approximately every 15 seconds.

That enables workflows that react to change on write:

• An agent updates a case in Lakebase.
• The change appears in a governed Delta history table.
• A Lakeflow pipeline, materialized view, or Structured Streaming job processes the new event.
• Analytics, audit history, models, or another workflow can respond.

This is especially valuable for agentic systems because it creates an observable record of what the agent changed. Operational state remains in Postgres, while the lakehouse receives an append-only history that can support auditing, monitoring, evaluation, and downstream automation.

Lakebase Change Data Feed is currently in Public Preview, so its limitations and production-readiness requirements should be reviewed for each workload. It is also asynchronous rather than part of the original Postgres transaction. Even with those qualifications, it is a powerful foundation for building agents that can take action without making their actions invisible.

Why Lakebase is our OLTP recommendation

Lakebase is still Postgres, which means applications can use familiar drivers, SQL, frameworks, and development practices. What makes it different is its position inside Databricks.

For teams already using the Data Intelligence Platform, Lakebase closes the gap between the application and the lakehouse:

• The database is managed from the same workspace as the rest of the data platform.
• Lakehouse data can be served through Postgres without a custom reverse-ETL solution.
• Transactional and analytical data can be joined in one query.
• Agent writes can become governed, incremental data for downstream workflows.

There are still reasons to choose another OLTP platform, particularly when an organization is not invested in Databricks or has database requirements Lakebase does not support. But when Databricks is already the center of the data and AI architecture, Lakebase is more than a convenient Postgres offering. It is the connective tissue between real-time applications, analytical data, and the agents increasingly operating across both.

That is why we highly recommend Lakebase as the default OLTP choice for new applications built on Databricks.