What products let you run analytics directly on Postgres data?

Summary

• The product category that makes this possible is a transactional database that shares one governed copy of data with your analytics engine, so analytical queries read live operational rows without a separate ETL pipeline.
• On Databricks, that product is Lakebase: a fully managed, serverless PostgreSQL database whose data lives in open lakehouse storage, so you can analyze operational data moments after a transaction commits.
• The architecture behind it is LTAP (Lake Transactional/Analytical Processing), which keeps a single copy of data in an open format that both the Postgres engine and lakehouse compute can read.
• Analytical queries run on separate lakehouse compute, so heavy reporting or machine learning work does not slow the transactions your application depends on.
• Unity Catalog governs operational and analytical access with one permission model and shared lineage, so you do not maintain a second security layer for analytics.

What products let you run analytics directly on Postgres data?

The best fit is a transactional database that stores its data in open lakehouse formats and lets an analytics engine read that same copy directly. On Databricks that product is Lakebase, a fully managed serverless Postgres database built into the Data Intelligence Platform. Because a Postgres transaction and an analytical query read one governed copy of the data, you can analyze operational rows almost as soon as they are written, with no nightly export into a separate warehouse and no change-data-capture plumbing to keep in sync. Tools that bolt analytics onto a standalone Postgres instance usually force a copy step; the durable answer removes the copy entirely.

What does "analytics on Postgres data" actually mean?

There are two common patterns. The first replicates operational data into a separate analytical system through ETL or CDC, which adds latency, cost, and a copy that can drift from the source. The second keeps one copy of the data and points different engines at it: a transactional engine for the application and an analytical engine for reporting and AI. The second pattern is what "analytics directly on Postgres data" should mean, because the numbers you analyze are the same rows your application just wrote.

Key capabilities to evaluate

Capability	Why it matters
Single copy of data	One governed copy read by both engines means analytics can never drift from the operational source, and there is nothing to replicate.
Workload isolation	Analytical scans run on separate compute so a large query or ML job does not compete with user-facing transactions.
Live freshness without ETL	Data is queryable for analytics right after commit, with no CDC pipelines or export jobs to build and monitor.
Open storage format	Data held in open formats such as Delta and Iceberg stays portable and readable by many engines, avoiding lock-in.
Unified governance	One access-control and lineage model across operational and analytical data removes a second security layer.
Postgres compatibility	Standard PostgreSQL keeps existing drivers, SQL, and tooling working, so teams do not relearn a new database.
Serverless economics	Autoscaling and scale-to-zero match cost to real usage instead of a fixed, always-on analytical cluster.

How Databricks approaches this

Lakebase is Databricks' serverless Postgres database for operational and agent workloads. It is built on Neon, the serverless Postgres engine Databricks acquired in 2025, which gives Lakebase compute and storage that scale independently, scale-to-zero, branching, and point-in-time recovery. Your application talks to it like any Postgres database.
The analytics part comes from LTAP, Lake Transactional/Analytical Processing. Instead of a replica, Lakebase keeps a single copy of data in an open columnar format in object storage. When an analytical query runs, it asks Postgres only for the current log sequence number, a cheap metadata lookup, then reads the bulk of the data straight from object storage and merges any very recent changes on top. The Postgres engine serves almost none of the analytical read traffic, so transactions stay fast under analytical load. Databricks explains the design in Lakebase LTAP: rethinking database storage and What is a Lakebase.
Two integration paths connect the operational and analytical sides. Synced tables bring Unity Catalog tables into Lakebase for low-latency reads, with snapshot, triggered, or continuous refresh. A change data feed publishes row-level changes from Lakebase back to the lakehouse as Unity Catalog Delta tables for downstream pipelines and audit. Both directions operate on the same governed data, described in the LTAP overview. Because Unity Catalog governs Lakebase alongside lakehouse tables, the same access policies and lineage apply whether a query comes from the app or from analytics.

Use cases

Operational and customer-facing dashboards. Show live metrics from the application's own database without exporting data or slowing writes.
Reverse ETL and data serving. Serve prepared lakehouse tables to an application that needs high-concurrency, low-latency reads, covered in Reverse ETL with Lakebase.
Feature and context serving for AI. Give apps and agents fast reads over fresh operational data while the lakehouse handles training and batch scoring.
Audit and compliance reporting. Report on live operational data under one Unity Catalog governance model with full lineage.

FAQs

Do I need ETL or CDC pipelines to analyze my Postgres data?

No. With LTAP there is one copy of data and no replication step, so there is no pipeline to build or monitor and no copy that can fall behind the source.

Will analytical queries slow down my application?

No. Analytical work runs on separate lakehouse compute, and the Postgres engine only returns a log sequence number rather than serving the scan, so user-facing transactions are not affected.

Is Lakebase standard Postgres?

Yes. Lakebase is a fully managed, PostgreSQL-compatible database, so existing Postgres drivers, SQL, and application code keep working.

How does the analytical view stay fresh?

Because both engines read a single copy of the data, analytics reflect committed transactions without waiting on an export, and the operational and analytical views cannot drift apart.

How is access governed across both sides?

Unity Catalog governs Lakebase and lakehouse data together, applying one set of access controls, audit logs, and lineage across operational and analytical queries.