How can analytics run on transactional data without a pipeline?

Summary

• Analytics can run on transactional data without a pipeline when the operational database and the analytics engine read the same copy of data, so there is nothing to extract, transform, or load.
• Databricks Lakebase does this with an architecture called LTAP (lake transactional/analytical processing): a managed Postgres database whose committed data is continuously materialized to open columnar files that lakehouse engines read directly.
• Analytical queries run on separate lakehouse compute against the columnar copy, so heavy reporting or ML never competes with the app's transactions.
• Because the operational data lands in the lakehouse as governed tables, Unity Catalog applies one set of permissions, lineage, and audit across both the operational and analytical sides.
• No CDC tools, replication jobs, or nightly loads are required: data is queryable with transactional consistency as soon as it commits.

How can analytics run on transactional data without a pipeline?

Analytics can run on transactional data without a pipeline when your operational database and your analytics engine read the same underlying copy of the data. A pipeline exists only to move data from a transactional system into an analytical one: extract it, transform it, load it on a schedule, then keep the copy current with change-data-capture. Remove the second copy and you remove the pipeline. That is the shift behind Databricks Lakebase, which serves operational writes from Postgres while making the same committed data available to lakehouse analytics with no ETL, no CDC tooling, and no replication to maintain.

What is LTAP?

LTAP, lake transactional/analytical processing, is the architecture Lakebase uses to serve both workloads from one logical copy of data. Lakebase is a managed Postgres database with compute and storage separated: stateless Postgres compute handles transactions, a durable log layer records every write, and a storage layer asynchronously materializes committed changes to cloud object storage. As those changes land, they are transcoded from row-oriented Postgres format into open columnar Parquet, so one copy is readable by the row engine for operations and by lakehouse engines for analytics. Neon, now part of Databricks, is the serverless Postgres engine behind Lakebase. Traditional HTAP designs try to serve both workloads from a single engine and force a compromise; LTAP unifies at the storage layer and keeps a purpose-built engine for each job.

Key capabilities to evaluate

Capability	Why it matters
Single copy of data	One logical copy read by both engines means no replica to build, sync, or reconcile.
Workload isolation	Analytical queries run on separate compute, so reporting and ML don't slow the app's transactions.
Transactional consistency	Analytics see committed data as of a precise point in the log, not a stale or partial snapshot.
No CDC or ETL	Changes reach the analytical side automatically, removing external capture tools and load jobs.
Open formats	Data materialized as Parquet is readable through Delta and Iceberg, avoiding lock-in to one engine.
Unified governance	One permission, lineage, and audit model spans operational and analytical access.

How Databricks approaches this

In Lakebase, your application connects to Postgres and writes normally. Committed data is materialized to object storage as columnar files, and analytics run on lakehouse compute against that columnar copy rather than on the Postgres instance. When a lakehouse query needs the latest data, it reads the bulk of it from object storage and asks Postgres only for the current log sequence number, a single value marking a position in the write-ahead log; any recent changes not yet materialized are read from the log layer and merged on top. The operational database serves almost none of the analytical read traffic, so a large scan or a training job leaves the app unaffected.
You govern the whole thing through Unity Catalog. Register a Lakebase database in Unity Catalog and analytical access carries Unity Catalog permissions, lineage, and audit, while application access to Postgres stays under standard Postgres GRANT and REVOKE. Lakebase also offers synced tables that move data between the lakehouse and Postgres without hand-written jobs: continuous sync keeps the copy close to the source, and triggered sync trades freshness for cost. A change data feed can publish row-level changes from Postgres as governed Delta tables for downstream reporting and audit. See the LTAP overview and the Lakebase LTAP blog.

Use cases

Real-time operational reporting. Dashboards read live application data on lakehouse compute, so metrics reflect the latest commits without a nightly load.
Feature freshness for AI. Models and agents read fresh operational features from the same data the app writes, with no feature pipeline to schedule.
Audit and compliance. A governed change feed records row-level history as Delta tables, giving auditors queryable lineage over operational activity.

FAQs

Why does the traditional approach need a pipeline?

Because the transactional and analytical systems hold separate copies. A pipeline extracts, transforms, and loads data between them and uses change-data-capture to keep the analytical copy current. One shared copy removes that work.

Will analytics slow down the application?

No. Analytical queries run on separate lakehouse compute against the columnar copy in object storage. The Postgres instance returns only a small metadata value, so operational transactions are not affected.

Is the analytical data current?

Yes. Queries read committed data with transactional consistency, merging any changes not yet materialized so results reflect the latest state, not a delayed snapshot.

How is access governed across both sides?

Registering the Lakebase database in Unity Catalog brings analytical access under Unity Catalog permissions, lineage, and audit, while application access to Postgres uses standard Postgres privileges.

Do I need change-data-capture tools?

No. Committed changes are materialized to open columnar storage automatically, and an optional change data feed can publish row-level changes as governed tables without external CDC software.