Imagine your refrigerator is located in a separate building 100 meters away from your kitchen. Every time I cook, I walk through each ingredient and come back to make sure the refrigerator door is closed. If you forget milk for your morning coffee, you might end up walking the long way again.
Until the age of agents, this was the norm. Data is stored in that refrigerator and may be retrieved as needed. Applications and humans no longer needed milliseconds of data or even live data to make important decisions. Humans can manipulate copies. But those days are coming to an end. Agents think and act instantly depending on the situation. And soon, those billions will be working 24/7. They don’t take out a copy and decide later. They need to be managed according to the circumstances of the moment, and they need to act quickly and at a reasonable cost. Agents can’t run to the lake or to the refrigerator, but these requirements are still met.
This means intelligence must reside where agents and data operate.
Consider the exponential rise in digital fraud in payment systems and the amount of money returned to retailers from digital purchases. We live in a world of more complex and integrated data and expect real-time solutions, solutions and options.
The lake was never built to run a business (or agent)
AI and data must be available the moment an agent takes action. Petabytes of data are provided live, in real time, do not have You can make copies without having to go to the refrigerator every time. You can’t renovate your lake house to make that happen.
Everyone now agrees that the old separation between transactional and analytical systems needs to end. The interesting question is what will replace it. This month, Databricks provided an answer: LTAP (Lake Transactional/Analytical Processing). Serverless Postgres built on Lakebase®LTAP places transactions and analytics on a single copy of the data in the lakehouse. This is interesting engineering, but it’s built from the wrong direction.
The reason is simple. All that matters is the data. Actions happen at the data tier, and governance needs to happen at the data tier, so the data tier is where you build your data, not where it goes. Upgrading your deal to a lake house is like moving your home and kitchen to a building with a refrigerator.
Lakehouse is fundamentally built on a data lake, and the lake was built for analytical work such as large-scale scans, append-heavy patterns, eventual consistency, and object storage economics. Transactions want the opposite. That means low-latency reads and writes, strict consistency, row-level locking, and the hard ACID guarantees that production applications have relied on for 40 years. You can definitely design a transactional layer on top of object storage, but you’ll be swimming against the board the whole time. Lakehouse is a great place to analyze data, but a strange place to manage order books.
The transaction already exists in the production database. It is a consistent and controlled system of records. Agents do not act on copies. They act on authenticity, live and govern where it is located. A durable architecture doesn’t take it into the analytical world and re-solve consistency from scratch. Start in the operational core where your business actually operates, and extend analytics, vector searches, and agents outward from there without moving the same live, managed data.
The destination everyone is describing is the same. One copy, no pipelines, one managed surface for all workloads, whether OLTP, HTAP, or agents. Discrepancy is the starting point. The lakehouse-first model predetermines that data belongs to the lake and pulls up transactions accordingly. Starting with an operational core assumes nothing. Your data stays where it is, and everything gathers there.
Opposite starting points compound. The more we build, the more the gap between the two will only widen.
For regulated businesses, true sovereignty is non-negotiable
Lakehouse is a cloud service that resides on cloud object storage and is under the control of the cloud. For most enterprises that need agent AI the most (banks, hospitals, telcos, governments), “move your transaction record system to our cloud” is not an implementation detail. It’s a non-starter. These organizations operate under data residency rules, sovereignty requirements, and, in some cases, air-gap obligations that no amount of elegant lakehouse architecture can eliminate. We cannot regulate where part-time workers physically sit.
This is not just a matter of what regulators will allow. Where the data works should be chosen by the company at the time, not a destination predetermined by the vendor.
The moment autonomous agents can operate on regulated data, sovereignty ceases to be a priority and becomes a constraint. Built on open Postgres, the production core can run anywhere your data needs to live, including on-premises, hybrid, across clouds, and air-gapped as required by regulators. Lakehouse is cloud-bound by design and runs wherever the vendor’s cloud runs. For regulated companies, that one fact settles the question before any benchmarking is performed.
Manage where your data resides, not the catalog above it
Governance works similarly. The Lakehouse model is managed through the Catalog, which is a policy layer managed on top of a collection of engines. It is a rational design for a platform that can be assembled from many parts. For autonomous agents that act directly on data, any governance layer that exists outside of the data is a governance layer that has a path around it.
Governance must be enforced by the database itself, through the same roles, row-level security, and audit trails that already govern human access. Manage where your data is at the moment of action, not in the catalog where it resides.
The market is already moving
This is a change and the market is confirming it. The most prominent companies in the Lakehouse world are currently racing to include an operational Postgres core, and are spending about $1 billion to acquire Neon to get there. Once the company that defined the lake house begins building toward an operational database, the direction of the move is no longer up for debate. The only question remaining is which end to build from.
Companies that get this right will work outward from their operational core, building on open Postgres and infrastructure they own. Transactions, consistency, governance, and sovereignty are tough constraints. Analysis is the part that should be provided to them, not the other way around. AI, data, and rules on the infrastructure you manage.
Join the era of agent 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
