Governance Moves Down the Stack
On June 23, EDB launched a set of capabilities for EDB Postgres AI that it describes as an agentic database, converged analytics, and a governance layer, all built on a Postgres foundation that enterprises own and run themselves. The framing is deliberately contrarian. While much of the industry is racing to build agent control planes as separate products that sit above the data, EDB is arguing that the right place to govern an agent is inside the database where the data already lives.
CEO Kevin Dallas put the thesis plainly: agents act in the moment, on live data, under real rules, and you do not get speed by reaching into a cloud for a copy. Chief Engineering Officer Max Romanenko added that EDB put the intelligence in the database, on infrastructure the customer owns, calling it a database that runs itself on the customer's terms. It is a clear shot at architectures that ship data out to a separate analytics or agent tier.
How the Control Layer Works
The governance mechanism, currently in preview, is the most interesting part for enterprise architects. Rather than treating agent permissions as a policy file in some orchestration tool, EDB enforces access through Postgres's own roles and row-level security. An agent's identity, its declared purpose, its permissions, and the enterprise's policies are fused into a single constrained query that the database executes natively, with full session-level audit trails attached.
The appeal is that the control cannot be bypassed by a misbehaving or compromised agent, because it is the database, not the agent, that decides what data a given session may touch. This is the inverse of the dominant pattern, where agents hold broad credentials and a separate layer tries to police their behavior. If the rules live in the data tier, an agent simply cannot retrieve what its session is not entitled to, regardless of how it was prompted or who built it.
The Performance Claims
EDB is not shy with numbers. It claims database tuning runs 10x faster through a self-optimizing engine monitoring more than 200 metrics, application performance accelerates up to 8x, and query latency is 99.4 percent lower than Databricks. Single-node queries run up to 30x faster, analytics total cost of ownership drops up to 58 percent, and a zero-ETL converged analytics architecture delivers data freshness of 12 milliseconds versus 3.8 seconds, a 99.7 percent improvement.
Vendor benchmarks always deserve scrutiny, and these are no exception. But the underlying argument is sound regardless of the exact multiples. Every hop your data takes between systems, every copy made for a separate analytics or agent platform, adds latency, cost, and a new surface where governance can slip. Collapsing analytics and agent execution into the operational database removes those hops by design. The performance story is really a corollary of the architecture story.
The Sovereignty Angle
EDB is wrapping this in the language of sovereign AI, and it has partners reinforcing the message. IBM's worldwide director for the ISV ecosystem, Unnikrishnan Rajagopal, said IBM Power and EDB Postgres AI are equipping enterprises for the AI-native era with secured, sovereign, AI-ready infrastructure. Korea's Kyobo Book Centre is cited as an early customer. The pitch lands hardest with regulated industries and jurisdictions where shipping data to a hyperscaler's cloud is a compliance problem, not a convenience.
For a CTO in banking, healthcare, or the public sector, the proposition is concrete: keep the data, the analytics, and the agents on infrastructure you control, and enforce policy at the layer that is hardest to circumvent. As data residency rules tighten and AI sovereignty becomes a board-level phrase, an architecture that never moves the data out is a genuinely different answer from one that moves it and then tries to govern the copies.
Reframing the Buying Question
The strategic value of this launch is that it reframes a question many enterprises are getting wrong. The dominant procurement conversation right now is which agent platform to standardize on, as if the agent is the thing that needs governing. EDB's move suggests the more durable question is where in the stack control should be enforced. If the answer is the data layer, then the choice of agent framework above it matters far less, and lock-in to any one agent vendor matters less too.
We would not declare a winner in the agent-governance debate on the strength of one product launch. Hyperscaler control planes have real advantages in breadth and integration. But EDB has articulated the cleanest version of the counter-argument we have seen this quarter, and it forces a useful discipline: before buying an agent platform, decide where your non-negotiable controls will live. If they live anywhere other than next to the data, you are trusting the agent to police itself, and the past year has given enterprises plenty of reasons not to.
