Imagine your refrigerator sits in another building, 100 metres from your kitchen. Every time you cook, you walk over for each ingredient, then walk back to check that you closed the fridge door. That could be another long walk back if you forgot the milk for your morning coffee.
Until the agentic era, this was the norm. Data could live in that fridge and get pulled when needed. Applications and humans didn't need millisecond or even live data to make important decisions; humans can work on copies. But that era is ending. Agents think and act in instants, in context. And very soon billions of them will be working 24/7/365. They don't pull a copy and decide later. They need to be governed in the moment, in the context of that moment, and they need to act fast and at reasonable cost. Agents cannot run to a lakehouse, or a fridge, and still meet those requirements.
That means intelligence has to be where the agents and data are acting.
Think about the exponential rise in digital fraud in payment systems, or the volume of retail returns from digital purchasing. We live in a more complex, integrated data world, and we expect real-time resolutions, solutions, and choices.
The lake was never built to run a business (or agents)
Your AI and your data need to be available the moment an agent acts: Petabyte-scale data, served in real time, live, not copies, without a walk to the fridge every time. You cannot retrofit a lakehouse to deliver that.
Everyone now agrees that the old separation between transactional and analytical systems had to end. The interesting question is what replaces it. This month Databricks offered its answer: LTAP, or Lake Transactional/Analytical Processing. Built on Lakebase, its serverless Postgres®, LTAP puts transactions and analytics on a single copy of data in the lakehouse. It is interesting engineering, but built from the wrong end.
The reason is straightforward: the only gravity that matters is the data. Action happens at the data layer, governance has to happen at the data layer, so the data layer is where you build rather than somewhere you move data to. Pulling transactions up into the lakehouse is like moving the house and kitchen to the building with the fridge.
A lakehouse is, at bottom, built on a data lake, and the lake was built for analytical work: Large scans, append-heavy patterns, eventual consistency, object-storage economics. Transactions want the opposite: Low-latency reads and writes, strict consistency, row-level locking, the hard ACID guarantees that operational applications have relied on for 40 years. You can engineer a transactional layer onto object storage credibly enough, but you are swimming against the substrate the entire way. The lakehouse is a magnificent place to analyze data, but a strange place to run your order book.
The operational database is where transactions already live. It is consistent, governed, the system of record. Agents don't act on copies. They act on the real thing, live and governed, right where it sits. The durable architecture doesn't haul that into the analytical world and re-solve consistency from scratch. It starts from the operational core, the place the business actually runs, and extends analytics, vector search, and agents outward from there, against the same live, governed data, without moving it.
The destination everyone is describing is the same: one copy, no pipelines, one governed surface for every workload, whether OLTP, HTAP, or agents. The divergence is the starting point. A lakehouse-first model decides in advance that the data belongs in the lake, then pulls transactions up to meet it. Starting from the operational core presumes nothing: The data stays where it already is, and everything comes to it.
Opposite starting points compound: the gap between the two only widens the further you build.
For regulated enterprises, true sovereignty is nonnegotiable
A lakehouse is a cloud service, on the cloud's object storage, under the cloud's control. For an enormous share of the enterprises that most need agentic AI (banks, hospitals, telcos, governments), "move your transactional system of record into our cloud" is not a deployment detail. It is a nonstarter. These organizations operate under data-residency rules, sovereignty requirements, and, in some cases, air-gap mandates that no amount of elegant lakehouse architecture can make go away. You cannot regulate your way around where the bytes physically sit.
This is not only about what regulators permit. Where data does its work should be the enterprise's choice in the moment, not a destination a vendor decided in advance.
The moment an autonomous agent can act on regulated data, sovereignty stops being a preference and becomes a constraint. An operational core built on open Postgres runs wherever the data has to be: on-premises, hybrid, across clouds, air-gapped if the regulator demands it. A lakehouse, cloud-bound by design, runs where the vendor's cloud runs. For the regulated enterprise, that single fact settles the question before any benchmark is run.
Govern where the data is, not in a catalog above it
Governance works the same way. The lakehouse model governs through a catalog, a policy layer administered above a collection of engines. That is a reasonable design for a platform assembled from many parts. For an autonomous agent acting directly on data, a governance layer that lives somewhere other than the data is a governance layer with a path around it.
Governance has to be enforced by the database itself, through the same roles, row-level security, and audit trail that already govern human access. Govern where the data is, at the moment of action, not in a catalog hovering above it.
The market is already moving
This is the shift, and the market is confirming it. The most prominent name in the lakehouse world is now racing to embed an operational Postgres core, spending roughly $1 billion to acquire Neon to get there. When the company that defined the lakehousestarts building toward the operational database, the direction of travel is no longer in dispute. The only question left is which end you build from.
The enterprises that get this right will build from the operational core outward, on open Postgres, on infrastructure they own. Transactions, consistency, governance, and sovereignty are the hard constraints; analytics is the part that should come to them, not the reverse. Your AI, your data, your rules, on infrastructure you control.
Join the Era of Agentic AI with EDB Postgres AI. Watch the global digital event on demand: https://www.enterprisedb.com/join-the-era-of-agentic-ai-edb-postgres-ai