There's a reason the great universities keep their libraries and laboratories on the same campus as their students. Data, intelligence, learning and application in one place create a flywheel, the thing that makes Oxford, Stanford and MIT matter. It isn't any single capability; it's the intensity of all of them, concentrated by design rather than bolted together after the fact. Those campuses produce Nobel laureates and company founders because they were built to bring out the best in what matters most, not retrofitted into it.
The same is true for AI and data platforms. Proximity and sovereignty win. Most enterprises want to run their own AI and data platform, yet only a small fraction have succeeded, and the ones who have share one trait: a sovereign control plane where every layer works together across unified data, runtime, governance and access control. They closed the gap between aspiring to be a data-and-AI platform and becoming their own AI operating system.
Keep that idea in mind: Proximity plus control at the center. The agentic era is about to test it harder than anything before it. Databricks recently acquired Electric, the team behind a WASM build of Postgres small enough to run inside an agent's sandbox, folding it into Lakebase alongside a real-time sync engine: lightweight Postgres at the edge, synced back to a central platform for durability and control. It's a smart acquisition. It's also a tell. When the largest platforms race to plant a flag in Postgres-for-agents, the question isn't whether Postgres won. It's which half of the problem the acquisition solves, and who ends up owning the half that matters.
That Postgres has won isn't an EDB talking point. Ask the architects doing the evaluations. Florian Zeba, Principal Enterprise Architect for Data & AI at ORBIS Austria, says it plainly: for PoC and MVP work, Postgres is the default, especially for anything AI-related. What's telling is where he says it stops. Standard pgvector holds sub-20ms p99 latency to roughly 5–10 million vectors; past that, the HNSW index outgrows memory and latency degrades sharply. That's exactly where a primitive stops and a platform begins.
Agents break the assumptions traditional infrastructure was built on. They decide what data they need at runtime, run in sandboxes with only a network path home and operate in fleets where every agent needs a live view of what the others just did. That's two problems the industry keeps collapsing into one.
The first is fast local context, a lightweight database right where the agent runs. That's the half Electric solves, and it's genuinely useful. It's also the easy half.
The second is the record: one durable, governed version of state a hundred non-deterministic agents can read and write without drifting into conflict or corruption. This is the hard half. Who owns the record, how writes reconcile, how retrieval stays fast once vector counts pass the threshold. An edge primitive and a sync engine move data around. They don't govern it, and they don't solve for performance at the center. This is the campus principle in technical form: the intelligence and the authoritative record have to live together, by design, not sit in a sandbox with a network path back to a system of record someone else controls.
On performance, the numbers are worth a look. In independent benchmarking by McKnight Consulting Group this July, at 50 million vectors on normalized enterprise hardware, EDB Postgres® AI returned a median query latency of 50ms; Databricks came in at just over 4,000ms, with lower recall and higher cost per query. Retrieval and governance are different axes, but for a platform positioning itself at the center of Postgres-for-agents, the center is exactly where those numbers matter most.
And "sync it back to a central platform for control" is where the fine print lives. Control on whose terms? Governing the record means the database itself enforces what each agent may do, scoped to a role, granted only the privileges its task warrants and enforced at execution rather than in application code or a prompt you hope holds. Writes get gated before they touch the record, and every statement is captured for audit. Do that, and a fleet of agents becomes trustworthy. Skip it, and you've built a fast, distributed way to corrupt your source of truth. The catch with the acquisition model is that the center you sync back to is a proprietary control plane, offering durability and control on the platform's terms, on infrastructure you don't fully own.
What to weigh right now:
- Separate the two problems before picking tools. Fast local context and a governed record are different jobs. Ask any vendor which half they're selling you.
- Know your scale threshold. Pgvector is excellent to a certain range, then degrades. Know where your workload lands, and what the platform does past that line.
- Find the boundary that enforces permissions. Application code and prompts eventually fail. The durable answer is the database enforcing it, per agent, at execution, and gating every write.
- Demand full auditability. If you can't reconstruct what every agent did, statement by statement, you can't trust it or prove it to a regulator.
- Check who owns the center. If your record lives inside one vendor's control plane, you've rented the foundation of your AI strategy. Confirm you can run it on open Postgres, on infrastructure you control.
Postgres won the agent database because it already carries the transactional guarantees and operational maturity to put a governed record under an unpredictable workload, and because it does it in the open. That's the part worth protecting.
The universities figured this out centuries ago: put everything that matters in one place, under one roof, by design. Databricks just paid to own the edge. The center, which is the trustworthy, governed, portable, fast record every agent writes back to, is still yours to keep. The question is whether you control it, or rent it.
