In the age of agents, the distance between where business happens and where it gets analyzed becomes architectural debt, with a direct effect on risk, governance, and decision-making capacity.
For decades, data architecture accepted an almost natural split: transactional systems on one side, analytical environments on the other. It worked for a long time. In the age of agents, that split charges interest.
”The foundation is invisible until it isn’t”.
At Data + AI Summit 2026, Databricks announced LTAP, or Lake Transactional/Analytical Processing: an architecture that unifies transactions, analytics, streaming, and operational data on a single copy of storage in the lake. As Ali Ghodsi, Databricks’ co-founder and CEO, put it:
“For decades, complicated data infrastructure was a tax that teams were forced to pay. Then agents arrived (…) The infrastructure that powered the last era of computing is now the bottleneck that no one can afford. LTAP removes it.”
The stated ambition is high: rebuild the foundation of data architecture right as, according to Databricks itself, AI already helps developers write roughly 50 times more applications than before, many of them run by agents.
The problem: the business operates in one place and decides in another
In traditional architecture, data is born inside operational systems: core banking, ERP, CRM, service platforms, e-commerce, risk systems, collections, logistics, claims, or fraud prevention. This is the OLTP world, built to record the operation.
That data then moves through ETL, ELT, CDC, batch, or streaming pipelines into analytical environments. There it gets transformed, aggregated, modeled, and made available for BI, data science, governance, AI models, and business applications. This is the OLAP world, built to interpret the operation.
This model created value, and it created dependencies. Every copy of data raises the cost of storage, processing, and control, and every pipeline adds latency, fragility, and maintenance. Add to that the inconsistency each intermediate layer introduces, plus the separate access, audit, lineage, and retention policies every isolated environment demands.
The result is familiar to many CIOs and CTOs. The company invests in data and still argues about which number is correct. It invests in AI and struggles to explain where the data came from. It modernizes platforms and, even so, stays tied to critical, poorly visible pipelines.
The question that matters today is a single one: does the business have a reliable foundation to turn operational data into an auditable decision?
What LTAP is
LTAP stands for Lake Transactional/Analytical Processing. According to Databricks, it brings transactional processing, analytical processing, streaming, data applications, and AI together on a governed lakehouse foundation, eliminating ETL, replicas, and pipelines by design.
In simple terms, LTAP joins the place where the business happens with the place where the business gets analyzed. Applications, analytics, and agents work on the same copy of data, under unified governance through Unity Catalog.
This convergence coexists with legacy systems. Older transactional systems remain in place, and not every OLTP or OLAP workload needs to migrate to a single platform. Even so, the rigid split between operational and analytical data is becoming harder to sustain for anyone running AI in production.
Why this matters in the age of agents
Generative AI brought a first wave of productivity: copilots, assistants, semantic search, text generation, document analysis, and task automation. The next wave is more demanding, because agents take action.
A corporate agent checks a customer’s status, assesses risk, recommends an action, triggers a workflow, logs the decision, and monitors the impact. It runs in a continuous loop: it reads context, interprets data, decides or recommends, executes, logs the result, and learns from the outcome.
That loop requires fresh data, reliable context, consistent governance, and the ability to write back to the right systems. When operational data lives in one environment, analytical data in another, models in a third layer, and agents operate outside that chain, the architecture turns fragile. The agent reads stale data, ignores a policy, uses an inconsistent metric, acts without traceability, or produces a result that is hard to audit.
For regulated or mission-critical businesses, that is a trust problem, with a direct impact on risk and audit.
How Databricks frames LTAP
LTAP builds on Lakebase, launched in 2025 as a serverless Postgres database integrated with the lakehouse. According to Databricks, Lakebase already serves thousands of customers, including Block, Ensemble, Superhuman, and Zillow, and processes 12 million database launches a day. As Grant Veazey, CTO of Ensemble, put it about the foundation built with Databricks:
“Lakebase and LTAP extend that foundation by unifying operational and analytical workloads on a single layer, giving our RCM-native AI the real-time access it needs to perform in live operations.”
Governance runs on Unity Catalog: unified identity, permissions, audit, and lineage for data and AI assets, across both Lakebase and the lakehouse. Around that foundation, Databricks also introduced other pieces of what it calls the agentic era: Genie One as an agentic data coworker, Agent Bricks for building agents on proprietary data, Omnigent for agent governance policies, OpenSharing for cross-organization data sharing, and applications such as Lakewatch (agentic SIEM) and CustomerLake (agentic CDP).
Together, these pieces support Databricks’ central narrative: applications, analytics, agents, and governance run on one shared foundation. Worth noting: per the official press release, LTAP “is coming soon as a part of Lakebase” — this is an announced architecture, not yet generally available.
Another piece of that foundation is Lakehouse//RT, a new real-time warehouse, currently in beta, whose Reyden engine delivers, according to Databricks’ own tests, up to 16 times better performance than dedicated serving layers, with sub-100 millisecond latency at 12,000 queries per second.
Why this is relevant
The OLTP/OLAP split survived every technology cycle, from Oracle and Teradata to Snowflake and Redshift. The names changed every decade; the architecture stayed. Today, competitors respond through integration: Snowflake advances its own Postgres strategy, and Microsoft builds Azure HorizonDB. Databricks is betting on eliminating the split; its competitors, on integrating it better.
There is already a rehearsal for this story. When Databricks coined the term “lakehouse” in 2020, the idea was treated as an anti-pattern, and today most major cloud providers use the term. Skepticism about LTAP tends to follow the same path. Still, the honest counterpoint holds the line: no one has unified OLTP and OLAP in four decades, and the thesis still needs to prove itself at scale, across critical workloads, and under regulatory requirements, especially since LTAP itself remains in its launch phase.
The impact for CIOs and CTOs
For CIOs and CTOs, LTAP is a market signal: data architecture is entering a new phase. For years, the priority was consolidating data for analysis and then scaling analytics and machine learning platforms. Now the pressure is to build a foundation capable of supporting agents, intelligent applications, and automated decisions with confidence.
That shifts the executive agenda. The conversation widens: from modernizing the data stack to the organization’s ability to decide and act with confidence in complex environments. That is why a few questions become central:
- How many copies of the business’s critical data exist?
- What is the latency between an operational event and its analytical visibility?
- Who governs the data once it leaves the transactional system and reaches the AI layer?
- Does lineage let you trace a decision from the original event to the action taken?
- Can agents read and write data with control, context, and audit?
- Does the current architecture reduce or increase the surface for failure?
- Does the company have a data foundation or a collection of fragile integrations?
These questions carry more weight than picking a single tool, since the risk lives in the disconnect between the database, the pipeline, and the model, an effect none of them fixes alone.
LTAP shifts where complexity gets solved
LTAP does not solve organizational complexity on its own. Large enterprises still carry legacy systems, distributed domains, regulatory requirements, data residency constraints, legacy contracts, critical applications, and multiple platforms.
The real question is different. LTAP forces an architecture discussion: which data, decisions, and applications should stay distributed across separate layers, and which should converge onto one shared, governed foundation?
That decision requires judgment. Not every transactional workload belongs in the lakehouse, and not every analytical use case demands real-time. Whether an agent should be allowed to write back to operational systems calls for the same judgment, weighed by domain, criticality, latency, governance, cost, operational dependency, and business impact. Mature adoption starts with a diagnosis of the foundation.
The strategic read for mission-critical businesses
For highly complex businesses, LTAP surfaces a debt that usually stays invisible: the fragmentation between the systems that run the operation and the systems that support the decision. It shows up in familiar symptoms:
- multiple versions of the truth;
- dashboards that do not match operational systems;
- critical pipelines with no clear owner;
- executive decisions based on stale data;
- poor traceability between event, analysis, and action;
- difficulty scaling AI into production;
- inconsistent governance across data, models, and applications;
- dependence on manual integrations or reverse ETL;
- a growing surface for failure.
In agentic AI, these symptoms get worse, since the more autonomous the systems, the clearer the foundation needs to be. Agents amplify the consequences of a fragmented architecture.
What this means for data and AI strategy
Before accelerating agent adoption, assess whether the data foundation is ready to support automated decisions. The question goes beyond having models, pipelines, or a modern platform: it is whether the architecture lets operational data, analytical data, business context, governance, and execution work together with confidence. That calls for an integrated view of the foundation:
- Origin and ownership of critical data. Which data supports meaningful decisions? Where is it born? Who is accountable for quality, freshness, and meaning?
- Decision latency. How much time passes between an operational event and its availability for analysis, automation, or action?
- End-to-end governance. Do access, audit, lineage, and retention policies follow the data through its entire journey?
- Safe write capability. Do applications and agents record decisions or trigger systems with control, without creating operational risk?
- Decision observability. Does the organization track not just systems and pipelines, but decisions, impacts, and owners?
- The structural cost of fragmentation. How much of the data operation exists only to compensate for the split between transactional and analytical systems?
These dimensions separate real modernization from a tool swap.
TreeID’s role
At TreeID, we read LTAP as a signal of a larger shift: data, integration, AI, governance, and operations form a single foundation, not isolated disciplines managed in parallel.
When operational data does not talk to analytical data, governance does not keep up with execution, AI runs without enough context, and the architecture depends on fragile integrations, the bottleneck becomes the decision. TreeID works at the root: we help complex organizations understand their data foundation, identify structural risks, decide on architecture paths, and build the right capability with the team that carries co-responsibility for delivery.
In short, LTAP works best as an invitation to a more important question: does your architecture bring the event closer to the decision, or push it further away? The next step is assessing your data foundation before scaling agents into production. Talk to TreeID about the Foundation Review for data and AI. We are Databricks partners.
Sources
- Databricks Launches LTAP: The First Lake Transactional/Analytical Processing Architecture — press release, June 16, 2026
- From monolith to Lakebase to LTAP: rethinking the database from storage up — Reynold Xin, June 30, 2026
- A New Era of Databases: Lakebase — Ali Ghodsi et al., June 12, 2025 (updated February 24, 2026)
- Introducing Lakehouse//RT — June 16, 2026
- Lakebase (product page)
- Unity Catalog · OpenSharing · Lakewatch · CustomerLake
- Databricks Launches Genie One — June 16, 2026
- Contextual Policies in Omnigent — July 7, 2026