Databricks unveils Lakehouse//RT and LTAP to erase the serving tier for agents

Databricks is pitching a solution to a problem that has haunted data teams for decades, and now agents make it impossible to ignore: the infrastructure between “thinking” and “acting” is too slow, too fragmented, and too hard to keep consistent. At the Data + AI Summit on Tuesday, Databricks announced two products aimed at collapsing that infrastructure: Lakehouse//RT and LTAP. The headline promise is straightforward. Lakehouse//RT delivers millisecond query latency directly on governed Delta and Iceberg tables, eliminating the dedicated real-time serving tier enterprises have maintained alongside lakehouses. LTAP, short for Lake Transactional/Analytical Processing, stores Postgres-native transactional data in Delta and Iceberg format from the point of write, removing the ETL pipelines that have connected operational and analytical systems for decades.

In a briefing with VentureBeat, Databricks co-founder Reynold Xin framed this as “the holy grail for agents.” His logic is simple: as users “vibe code more applications,” agent systems that reason analytically on top of those apps need the underlying infrastructure out of the way so they can “move way faster.” Databricks is essentially arguing that what used to be a tolerable compromise for human-paced analytics becomes an operational risk when systems continuously reason and act on live data. In that world, a pipeline between an agent and the information it needs can turn into both latency and correctness debt.

To understand what Databricks is trying to replace, you have to zoom out to the long-running industry attempt to unify transactional and analytical data. In 2014, analyst firm Gartner coined HTAP, Hybrid Transactional/Analytical Processing, to describe vendors that aimed to blend the two database worlds. Vendors including MemSQL (now known as SingleStore), SAP HANA, and Oracle's MySQL Heatwave are among many HTAP players in the market. Databricks is not exactly claiming “HTAP failed,” but it is taking a swing at the industry’s overall approach. Xin told VentureBeat that “HTAP to us is kind of more of a failure of the industry rather than a success.”

The reason matters: HTAP has typically focused on engine convergence, while Databricks is pushing an idea that shifts the problem to storage-layer unification using its Lakebase architecture. Lakebase is Databricks' serverless cloud-based PostgreSQL database service that became generally available in February. Previously, Lakebase stored Postgres data in Postgres format on object storage, requiring conversion before lakehouse analytical engines could use it efficiently. With LTAP, transactional data lands directly in Delta or Iceberg format, sharing the same copy that analytical workloads read. Xin’s framing was “the whole point is, hey, you use the best tool for the job at the query engine level, we just make sure underlying storage is a single copy of the data.” Here, Postgres remains the transactional engine, and Spark plus the lakehouse remain the analytical engine.

Latency is where the pitch has to stop being philosophical and start getting engineered. Object storage response times are in the seconds range, which is far too slow for OLTP workloads that require sub-millisecond performance. Databricks says Lakebase solves this with a caching layer between Postgres compute instances and object storage. The key design choice is where the row-to-column conversion happens. Databricks’ approach uses idle CPU capacity in the caching layer to perform the conversion before the data lands in object storage. Xin said converting data from row to column “compresses more than 10 times, typically,” which reduces network cost between the caching layer and object stores. That detail is easy to gloss over, but it is central: caching layers can be quick, but only if the expensive transformations do not show up in the user-visible path.

So where does Lakehouse//RT fit? Databricks positions it as the answer to the dedicated real-time serving tier that enterprises have used alongside their lakehouses. That tier exists because traditional lakehouse query paths often cannot deliver the latency enterprises want for low-latency queries. But running a separate serving system creates classic pain: data copies, split governance, and pipeline complexity, all of which agent workloads cannot “work around.” Databricks says Lakehouse//RT includes a Reyden compute engine built for high-concurrency, low-latency serving. It queries Delta and Iceberg tables directly without moving data out of the lakehouse. The performance claims are specific: sub-100ms latency at 12,000 queries per second, with response times as low as 10ms on smaller datasets and up to 16x better performance than existing dedicated serving stacks. On governance, Databricks says every query runs within Unity Catalog’s governance framework with no separate permissions layer, no data copies, and no ingestion pipelines.

Analysts agree the pain is real, but they are skeptical about how quickly this turns from architecture narrative into operational proof. Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research, told VentureBeat that agents need live operational data, historical context, governance, retrieval, and write-back in the same workflow. She called the architecture argument “strong,” but added that Lakebase still has to prove it can meet the latency, reliability, and operational maturity CIOs expect. Mike Leone, analyst at Moor Insights and Strategy, focused on what could be the biggest scrutiny point: how both engines truly share one copy without a quiet conversion step doing the syncing in the middle. He also emphasized a potentially differentiating move: letting transactional writes land in open formats so the operational database is not trapped in a proprietary box while only the analytics layer is open.

Zoom out further, and Databricks’ timing starts to make market sense. Enterprises have spent years optimizing for human-speed analytical consumption, which made the traditional “best-of-breed tools for each workload type” approach and the pipelines between them feel defensible. Agents surface the gaps. They can detect inconsistencies across governance boundaries faster than any human team. And the market, according to VB Pulse Q1 2026, is moving toward hybrid retrieval intent, which tripled from 10.3% to 33.3% across the quarter, while standalone vector database adoption declined across every tracked vendor. The same consolidation logic is now hitting the real-time serving tier, because the agent-centric workload is not willing to tolerate extra copies and extra sync steps.

For decision-makers, the stake is whether you can simplify your stack without increasing the operational risk you already manage today. If agents really depend on live data with governance and write-back in the same workflow, then the question is no longer which tools to combine. It is whether running separate tools at all is still defensible, and whether Databricks can retire an entire row of specialized systems without hidden syncing, without latency surprises, and without reliability tradeoffs.