Databricks’ LTAP and Lakehouse//RT aim to slash AI agent latency

For years, data teams have grappled with a fundamental infrastructure challenge: bridging operational databases and analytical systems without sacrificing speed or governance. The rise of AI agents has intensified this problem, as these systems require uninterrupted access to live data to reason and act in real time.

At the Data + AI Summit, Databricks introduced two groundbreaking products to address this decades-old dilemma. The first, Lakehouse//RT, delivers sub-100ms query latency directly on governed Delta and Iceberg tables, eliminating the need for a separate real-time serving tier. The second, LTAP (Lake Transactional/Analytical Processing), stores PostgreSQL-native transactional data in Delta and Iceberg formats from the moment it’s written, removing the ETL pipelines that have historically connected operational and analytical systems.

“Agents thrive on simplicity,” said Reynold Xin, co-founder of Databricks, in an exclusive interview with VentureBeat. “A cleaner data stack allows them to move faster and reason more effectively.”

Why HTAP failed—and how LTAP differs

The concept of uniting transactional and analytical processing isn’t new. In 2014, Gartner coined the term HTAP (Hybrid Transactional/Analytical Processing) to describe vendors attempting to merge these workloads. Solutions like SingleStore, SAP HANA, and MySQL HeatWave emerged, but Xin argues these approaches often fell short by focusing on engine-level convergence rather than storage.

“HTAP was more of an industry failure than a success,” he stated. “The real breakthrough comes from unifying data at the storage layer.”

LTAP leverages Databricks’ Lakebase architecture, a serverless PostgreSQL database service released in February. Previously, Lakebase stored PostgreSQL data in native format on object storage, requiring conversion before analytical engines like Spark could process it efficiently. LTAP changes this by writing transactional data directly into Delta or Iceberg format, ensuring a single, shared copy for both operational and analytical workloads while retaining PostgreSQL for transactional operations.

“The goal isn’t to force a single query engine for every workload,” Xin explained. “Instead, we let teams use the best tool for the job at the query level while ensuring the underlying storage remains unified.”

The engineering hurdle here is latency. Object storage typically introduces second-scale response times—far too slow for OLTP workloads demanding sub-millisecond performance. Lakebase mitigates this with an intelligent caching layer between PostgreSQL compute instances and object storage. Idle CPU capacity in this layer converts rows to columns before data lands in storage, reducing network overhead and accelerating query performance.

“Columnar conversion compresses data by more than tenfold,” Xin noted. “This dramatically cuts network costs and improves caching efficiency.”

Lakehouse//RT: real-time queries on live lakehouse data

Enterprises have long relied on dedicated real-time serving tiers to support low-latency queries, but these systems introduce data duplication, governance gaps, and operational complexity—all barriers for AI agents. Lakehouse//RT eliminates these pain points by enabling direct, governed queries on Delta and Iceberg tables without moving data.

Key features of Lakehouse//RT include:

• Reyden compute engine: A purpose-built engine optimized for high-concurrency, low-latency serving, capable of querying Delta and Iceberg tables natively within the lakehouse.
• Performance metrics: Sub-100ms latency at 12,000 queries per second, with response times as low as 10ms on smaller datasets—up to 16x faster than legacy serving stacks.
• Governance integration: All queries run within Unity Catalog’s unified governance framework, eliminating the need for separate permissions layers, data copies, or ingestion pipelines.

“Agents need live operational data, historical context, governance, retrieval, and write-back capabilities—all in a single workflow,” said Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research. “Databricks’ agentic framing is what sets this apart from previous unification attempts.”

The road ahead: proving reliability at enterprise scale

While the architectural vision is compelling, analysts caution that execution will determine its long-term impact. Mike Leone, analyst at Moor Insights and Strategy, highlights that open analytics on data lakes has become table stakes, with many vendors offering similar capabilities.

“The differentiator lies in enabling transactional writes to land in open formats,” Leone noted. “But Lakebase must still demonstrate the latency, reliability, and operational maturity that CIOs demand before it can truly disrupt the market.”

For AI agents, the stakes couldn’t be higher. As these systems evolve to handle increasingly complex tasks, their dependence on seamless, governed data pipelines will only grow. Databricks’ latest offerings represent a bold step toward a future where data infrastructure no longer stands in the way of intelligent automation.