Databricks CEO Ali Ghodsi unveiled LTAP, a new architecture that collapses the 40-year unification problem of OLTP and OLAP databases.
Databricks
Every data company is adding an AI agent layer to the stack it already sells and calling it a strategy. Ali Ghodsi wants to rebuild the stack itself. The Databricks co-founder and CEO argues that enterprise AI is running into a much older problem than model intelligence. For decades, companies have operated two separate data worlds: one to run the business and another to analyze it. While the industry focuses on larger models and smarter agents, Ghodsi believes the real bottleneck sits deeper—in the infrastructure those systems depend on.
At its Data + AI Summit in San Francisco, Databricks unveiled LTAP, short for Lake Transactional/Analytical Processing, an architecture designed to collapse the long-standing divide between OLTP and OLAP.
"For forty years we’ve lived with a separation between OLTP and OLAP because the workloads were genuinely different," Ghodsi tells me, in a exclusive conversation. "The cost of maintaining those separate worlds is becoming increasingly hard to justify. Customers are paying for multiple data warehouses, dozens of database technologies, and operational overhead. For the first time, we think we've cracked the unification code."
The divide Databricks is targeting has survived every major technology cycle of modern computing. Oracle, PostgreSQL, SQL Server, Teradata, Snowflake, Redshift — the technologies changed, but the architecture didn't.
Transactional databases, known as OLTP, power websites, mobile apps, payment networks, and virtually every customer-facing application. But transactional systems were never built for broad analytical questions. Asking one to scan years of historical data risks slowing down the very production workload it exists to serve. "People wanted to know, what were our sales last year?" Ghodsi says. "You can't do that on this database, because it'll interfere with the production workload."
The answer was OLAP, or online analytical processing — separate warehouses optimized for reporting, forecasting, and historical analysis. Every copy created another pipeline to maintain, another bill to pay, another opportunity for data to go stale. "Architectures built for human-paced analytics become a problem when machine actors are continuously querying, branching, writing, recomputing, and making decisions," Ghodsi says. Agents want the latest operational state immediately — not a warehouse copy that's already stale.
The industry tried bridging the gap for years. Change data capture, or CDC, keeps a copy flowing between the two — but Ghodsi believes that copy is "always a little bit stale — an hour or a day behind. Another system, another copy, another bill." Likewise, HTAP amounted to two systems stitched together, and Zero ETL automated copying rather than eliminating it. Databricks itself wasn't immune to those tradeoffs. The company introduced synchronization capabilities in 2025 to move data between operational and analytical environments.
LTAP takes a more radical approach. Instead of synchronizing multiple copies of data, both transactional and analytical engines operate directly on the same dataset — a single copy on the lake, in low-cost cloud object storage, in an open format. The company's shorthand: "One data. Zero compromises. Zero copies." The ambition is not simply a new single source of truth but a single operational and analytical substrate. "That's the difference between improving the existing architecture and replacing it," Ghodsi says.
The foundation was Lakebase, Databricks' serverless PostgreSQL database from its roughly $1 billion Neon acquisition — built around an unlikely proposition: move transactional storage onto the lake, the same cheap object storage long considered too slow for operational workloads.
"The lake is slow and not reliable," Ghodsi says. "We made it reliable with safekeepers, and really fast with page servers and caches." Lakebase hit general availability on AWS in February, grew revenue twice as fast as the Lakehouse business in its first six months, and now handles millions of database launches a day for customers, including Block, Superhuman, and Zillow.
LTAP stores transactional data in Apache Iceberg — the open format used across the analytical Lakehouse — so one copy serves both worlds with no pipelines between them. "You get Lakebase plus Lakehouse. OLTP plus OLAP equals LTAP," Ghodsi says. "An OLAP engine that accesses one copy and an OLTP engine that updates the records. You don't even need CDC." Internally, the team briefly called it "minus-one ETL."
According to Ghodsi, LTAP wasn't originally conceived as an attempt to solve the 40-year divide between transactional and analytical databases. It emerged from a different problem: AI agents.
Unlike human developers, who might create a handful of databases and work with them for months or years, AI agents can create, test, and discard software environments in minutes. An agent writing code may launch multiple versions of an application simultaneously, try different approaches in parallel, analyze the results, and throw most of them away. To do that efficiently, it needs instant access to fresh data and databases that can be spun up on demand.
That requirement led directly to Lakebase, Databricks' serverless PostgreSQL database. By separating compute from storage, Databricks made databases dramatically cheaper to create, clone, pause, and restart — exactly the behavior agents were demanding.
Once Databricks had transactional databases running on lake storage, a larger question emerged: if operational databases and analytical systems could both live on the same underlying lake, why continue maintaining separate copies of the same data? That question ultimately became LTAP.
Databricks says roughly 80% of databases on its platform are now being created by agents rather than humans, a statistic Ghodsi sees as evidence that enterprise infrastructure is already being reshaped by AI. "Our primary user is already the agent," he says. "You simply can't have eighteen incompatible technologies, endless copies of data moving between them, multiple governance systems, and thousands of agents operating on top of all that complexity. That model doesn't scale."
When the company coined the term "lakehouse" in 2020, critics dismissed it as an anti-pattern; today, every major cloud vendor uses the term. Ghodsi expects critics to make the same argument they made about the lakehouse. Rather than debating whether the idea is new, he points to a more practical test: has anyone actually done it?
"Show me which company on the planet today does not have two copies — one for transactional databases like Oracle or Postgres, and one for Snowflake and whatnot. Who has merged these two? The idea is 40 years old, but nobody really pulled it off." He expects the next criticism to be that it won't survive production. With operational and analytical data in the same open format, agents can observe and reason across entire fleets of production databases. "You can have analytical agents that look over all your production databases, see which database is slow, which database is missing an index, and automatically start fixing things," Ghodsi explained.
Alongside LTAP, Databricks also unveiled Lakehouse//RT, a real-time analytics engine that brings millisecond dashboard workloads directly onto the lakehouse — no separate serving system required.
"Full ANSI SQL, directly on the lake," Ghodsi says. "You just get millisecond performance." The engine, Reyden, takes its name from an internal joke: co-founder Reynold Xin's team named it "Reynold's Dream Engine" on the theory that naming a project after a founder makes it harder to kill. It sustains sub-100-millisecond latency at up to 12,000 queries per second.
The competitive landscape has taken notice. Snowflake is pursuing its own PostgreSQL strategy; Microsoft is building Azure HorizonDB. But Ghodsi believes most competitors are still approaching the problem as one of integration rather than elimination.
“Our focus has consistently been on creating the next architecture, not optimizing the current one,” he says. “What we believe others still underestimate is that the future isn't about stitching together more categories of software. It's about eliminating categories. We're not trying to manage fragmentation better, rather aiming to remove it entirely."
One of Silicon Valley's more persistent rumors is that Databricks is considering a new funding round at a valuation between $165 billion and $175 billion, potentially as soon as next month. The speculation comes as the company is generating roughly $5.4 billion in annualized revenue. Ghodsi rejected the reports outright.
"If we really wanted maximum valuation, we would have IPO'd in the hottest market in the last two years," he says. "We are not fundraising and do not have term sheets from anyone. That's the honest truth."
If Ghodsi’s bet on agents as the dominant consumer is right, LTAP is a claim that the foundation of enterprise data has to be poured again, one that Databricks has already started pouring. The question is whether agents will become a permanent layer of digital labor inside companies, operating business systems alongside humans, or remain sophisticated assistants that work within the architecture enterprises already have.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。