By Every data team runs two databases. One for the app, one for the warehouse. A CDC pipeline connects them, and that pipeline is a tax you pay in engineering time, infrastructure cost, and weekly reconciliation meetings asking why the dashboard number doesn’t match the application number. On June 16, Databricks announced LTAP — and claimed it killed that pipeline for good.
Bold claim. It mostly holds up.
What LTAP Actually Is
LTAP stands for Lake Transactional/Analytical Processing. The idea is architectural, not cosmetic: instead of storing your operational data in Postgres and separately syncing it to a data warehouse, LTAP writes Postgres data directly to open-format files (Parquet, Delta, Iceberg) on object storage (S3). Both your transactional engine (Lakebase Postgres) and your analytics engine (Spark, SQL warehouse) read from those same files. One copy of data. Zero sync pipeline.
The before and after is concrete:
Before: App writes to Postgres → Debezium captures changes → Kafka topic → Spark job → Delta Lake → analytics team reads stale data
After: App writes to Lakebase Postgres → Postgres stores data as Parquet on S3 → Spark reads the same Parquet files directly
The CDC connector, the Kafka topic, the sync job — gone. Not optimized. Gone.
Lakebase: The Postgres Side of the Equation
The transactional half of LTAP is Lakebase, Databricks’ fully managed serverless Postgres. It went generally available on AWS in mid-2026. Azure is currently in public preview. Google Cloud is expected later this year.
For developers, the most important detail is that Lakebase speaks standard Postgres wire protocol. You connect with psycopg2, SQLAlchemy, or any other Postgres-compatible driver — no changes required:
import psycopg2
conn = psycopg2.connect(
host="your-lakebase-host.databricks.com",
port=5432,
database="your_database",
user="your_user",
password="your_databricks_token"
)Beyond the standard interface, Lakebase adds features that standalone Postgres doesn’t have:
- Instant branching: Copy-on-write clones of your entire database, created in seconds. Think git branches for your data — test a schema migration against a full production copy without spinning up another server or waiting for a dump-and-restore.
- Autoscale to zero: Billed in Databricks Units based on actual compute consumed. Idle databases cost nothing.
- Point-in-time recovery: Restore to any millisecond within the retention window — useful when a bad deploy corrupts production data at 2 AM.
- Unity Catalog integration: Same governance, same access control, same audit log as the rest of your Databricks data — operational and analytical data unified under one permission model.
Storage scales to 8TB per instance. A 14-day free trial is available. Get started at the official Lakebase documentation.
This Is Not HTAP With a New Name
The obvious pushback — and SingleStore’s CTO made it publicly — is that LTAP is just HTAP rebranded. “Renaming it LTAP changes the marketing. It doesn’t change the physics.”
Worth taking seriously. HTAP (Hybrid Transactional/Analytical Processing) promised to run both workloads in a single engine. It mostly failed because you can’t optimize one engine for low-latency writes and high-throughput scans simultaneously without compromising both. Databricks describes HTAP as “more of a failure of the industry rather than a success.”
LTAP’s answer is different: don’t try. Keep two specialized engines (Postgres for OLTP, Spark for OLAP), but put them on one storage layer. The engines stay optimized for their jobs. The data stays in one place.
The physics criticism is still partially valid. Object storage (S3) has roughly 10ms average latency. NVMe-backed Postgres delivers sub-millisecond writes. For workloads doing millions of small writes per second with tight p99 SLAs, Lakebase is not the right database today. The Register’s coverage summarizes the skeptic’s case well.
The AI Agent Angle That Actually Matters
The less-discussed driver behind LTAP is AI agent data freshness. Agents querying a warehouse are working with data that’s 12 to 24 hours stale. That’s fine for monthly reporting. It’s not fine when an agent is helping a customer support rep look at a transaction that happened 10 minutes ago.
LTAP gives AI agents direct access to operational data without a pipeline delay. An agent can read the same Parquet files the application just wrote to. For teams building agentic systems on Databricks, this is likely the most immediately useful implication — and it’s the angle Databricks’ own marketing leans hardest on.
Who Should Try It Now
LTAP makes immediate sense if you’re already on Databricks and running a Postgres workload, building AI agents that need fresh operational data, starting a new project and want to avoid building the CDC pipeline entirely, or if moderate write latency (dozens of milliseconds p99) is acceptable for your use case.
Wait and evaluate if you need sub-5ms p99 write latency, you’re on Google Cloud (GA not available yet), you’re not on Databricks and don’t plan to be, or if data sovereignty requirements prevent using cloud-managed object storage.
The Bottom Line
The two-database problem is real, and LTAP’s approach — one storage layer, two specialized engines — is architecturally cleaner than what came before. Lakebase is production-ready on AWS today, free to try for 14 days, and genuinely useful for teams already in the Databricks ecosystem.
For everyone else: watch the latency benchmarks, watch how Azure GA lands, and watch whether Databricks follows through on open-sourcing the LTAP Writer Library. The architecture is sound. The full production case takes a bit longer to build. For the technical deep dive behind the architecture, the Databricks engineering blog post is the best single resource available.
