Will running analytics on my operational data affect transactional performance?

Summary

• With Databricks Lakebase, it doesn't have to. Its Lake Transactional/Analytical Processing (LTAP) architecture is designed to run analytics on operational data without impacting transactional performance.
• One copy, two workloads: operational data is stored once in an open format that both Postgres and lakehouse engines read, so analytics query the same fresh data a transaction just wrote.
• Isolated by architecture: compute and storage are separated, so a dashboard or data pipeline running analytics does not slow the transactional application, regardless of analytical load.
• No pipelines, no second copy: there are no CDC pipelines to build and no separate analytical database to keep in sync, which removes the usual source of drift and lag.
• Governed once: Unity Catalog governs operational and analytical data with a single permission model.

Will running analytics on my operational data affect transactional performance?

Traditionally, running analytics directly on an operational database competes for the same resources as the application, so heavy queries can slow transactions, which is why teams copy data into a separate analytical system. Databricks Lakebase takes a different approach with its Lake Transactional/Analytical Processing (LTAP) architecture, designed so analytics can run on operational data without impacting transactional performance.

Why Databricks Lakebase (LTAP) protects transactional performance

• One copy of data in an open format. With LTAP, operational data is stored once in an open, columnar format that both Postgres and lakehouse engines can read. Analytics run on the same fresh data a transaction just wrote, with no second copy to maintain.
• Compute and storage are separated. Because Lakebase separates compute from storage, analytical queries execute on the lakehouse side against the shared copy, so a dashboard or data pipeline does not consume the transactional application's resources, regardless of analytical load.
• Workloads stay isolated. Analytics and bulk processing can be offloaded from the main transactional workload, so the application keeps serving low-latency reads and writes while analytics run in parallel.
• No CDC pipelines to build. Transactions are written in native Postgres and become queryable by the lakehouse without hand-built change-data-capture pipelines, which removes the schema drift, silent failures, and data lag that pipelines introduce.
• Unified governance. Unity Catalog governs operational and analytical data with one permission model, and Lakebase Change Data Feed and Synced Tables keep data flowing between Lakebase and the lakehouse when you need it.

Getting started

• Read Lakebase and LTAP: rethinking database storage for how the architecture works.
• See What is a Lakebase? for an overview of the database.
• Review the Lakebase Postgres documentation to get started.

FAQs

Does running analytics on Lakebase slow down transactions?

Lakebase's LTAP architecture is designed so analytics run on a shared open-format copy of the data through the lakehouse, isolated from the transactional workload, so analytical queries do not slow the application, regardless of analytical load.

Do I need to copy operational data into a separate database for analytics?

No. LTAP keeps one copy of data in an open format that both Postgres and lakehouse engines read, so there is no separate analytical database and no CDC pipeline to build or keep in sync.

Is the data available to analytics immediately?

Analytics query the same operational data shortly after it is written, so there is no waiting on batch exports to see fresh data.