How LTAP Eliminates The Data Pipeline Problem

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.

'Our Primary User Is Already the Agent'

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."

'We Are Not Fundraising'

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.