TL;DR. On September 24, 2026, Google previewed PostgreSQL for agents in AlloyDB, built on what it calls an agentic database architecture: agents connect over MCP to an ephemeral pool of microVM Postgres nodes that spin up in seconds, read production state from their own set of Colossus storage segments, and bill per second of activity. As an answer to the question "will a thousand agents take down my primary," it is the most complete isolation story any vendor has shipped. It is also, by design, an answer to only that question. Every node is read-only, so everything that makes agent access to a database genuinely hard, what the agent may read, what its reads mean, and what happens when it wants to write, is deliberately left standing where it was.
Google's announcement of the AlloyDB agentic database architecture is really two documents. The product post announces the preview of PostgreSQL for agents: serverless database instances with up-to-the-second read-only access to production, provisioned in seconds and spun down automatically. The engineering deep dive, by VPs Amit Ganesh and Sailesh Krishnamurthy, is the more interesting read, because it publishes the design space: three requirements any agent-facing database has to meet, and an argument that every existing architecture fails at least one of them.
It also lands in a crowded ten days. Cockroach Labs launched Continuum, its own agentic database cloud, on September 15. Neon said on September 24 that it is building a realtime sync engine into its Postgres platform because "modern apps and agents need realtime data and end-to-end reactivity." Three vendors converged on the same customer anxiety in under two weeks, and it is worth being precise about which part of that anxiety this architecture actually retires.
Three requirements, three failing architectures
The deep dive states its tenets plainly. Agents must read live production data with sub-second freshness over a data path that shares no database components with the primary cluster. Cache misses that reach remote storage must complete in under a millisecond, because agent reasoning loops issue operational queries, not warehouse scans. And compute must spin up in seconds, scale to thousands of nodes, run for short bursts, and drop back to zero.
Held against those three requirements, the existing menu looks bad, and Google walks through why:
- Independent replicas pass isolation and latency and fail scale. Provisioning a replica means rehydrating hundreds of gigabytes or terabytes of storage, which takes hours. Agent reasoning bursts are measured in seconds, so the elasticity arrives after the workload is gone.
- Disaggregated shared-storage designs pass latency and fail isolation, because every replica reads from the same storage servers as the primary. Google's phrase for this is the memorable one in the piece: shared allocations mean shared fate. Total storage bandwidth is fixed at the pre-provisioned tier, so agent I/O and production I/O compete for it.
- Object storage with shared block servers scales, but a block-server miss falls through to object storage at tens of milliseconds, and the block servers themselves are shared with production. Google reports testing one competing system built this way: adding replicas bought less than a 2x throughput increase, peaking at four replicas, while primary throughput fell by more than 75%. That is a vendor benchmarking its competitor, so apply the usual discount, but the failure shape it describes matches the architecture's own economics.
The claimed way out is infrastructure most vendors do not have. AlloyDB already stores data in Colossus, Google's distributed file system, which the deep dive credits with up to 15 TB/s of aggregate throughput to a single database. The agentic architecture serves agents from a separate set of Colossus segments, deliberately spread away from the production data path, so the isolation boundary extends through the storage layer instead of stopping at compute. On top of that sit the agent nodes themselves: each one a full AlloyDB Postgres engine in a lightweight microVM, provisioned when an agent asks over MCP, billed per second, gone when the reasoning loop ends.
The architecture in one picture. The boundary between agent I/O and production I/O runs through the storage layer, not just the compute layer, which is the part existing replica designs cannot claim. Scaling numbers are Google's own.
The benchmark Google publishes for it is an index-lookup workload: 3.9K QPS on one agent node, 41K on ten, and 3 million QPS across a thousand, with over 8 million IOPS reaching Colossus and, in a separate scan test, 2,100 nodes pulling more than a terabit per second. The scaling is close to linear, and Google reports no measurable impact on the primary cluster while it happens. Worth noting before reusing those numbers: index lookups are the friendliest possible workload for this claim, embarrassingly parallel reads with no coordination, and no one outside Google has reproduced any of it yet.
Read-only is the load-bearing word
Both posts repeat the phrase "read-only" the way announcements repeat things they consider a feature, and here it genuinely is one. The bet underneath it is a claim about what agent database workloads look like: reasoning loops that interrogate schemas, sample rows, run aggregates, join lakehouse data, and issue thousands of small queries on the way to a conclusion, with writes rare, precious, and handled elsewhere. On the evidence of how agents actually use databases, heavy exploratory reading with occasional writes, that bet looks right.
What the boundary buys is blast radius. A runaway agent loop against this architecture produces a bill, not an outage. After a year in which the standing fear was an agent taking production down by accident, that is a real product, and pricing it per second of activity is honest about what it costs.
What the boundary defers is everything on the other side of it. Two things specifically.
Writes never got easier. The moment an agent concludes its investigation and wants to act, add the index, fix the row, run the migration, it leaves the sandboxed pool entirely and lands on the production write path, where none of this machinery exists and all of the old questions apply: who approved this, what does it lock, what happens at rollback. The architecture is explicit about this scope and does not pretend otherwise. But it means the hard half of agent database access, the half where the incidents live, is untouched by the launch.
Reads did not get governed, either; they got fast. Every agent node exposes what the announcement proudly lists as "every index, the full capability of SQL, and comprehensive vector, full-text, and spatial search" over the freshest possible production state. Isolation protects production from agents. It does not protect data from agents, and it does not help the agent be right: nothing at the storage layer knows which of three revenue columns is the governed one, whether the table the agent found is live or abandoned, or whether this particular agent should see customer rows at all. We made the longer version of this argument in read-only isn't enough, and it applies here at a thousand nodes of scale: a perfectly isolated wrong answer is still wrong, delivered with sub-millisecond I/O.
There is a cost corollary too. Per-second billing on ephemeral nodes is the same deal we examined in what Postgres autoscaling can and cannot optimize: elastic infrastructure converts bad queries from a stability problem into a spend problem. An agent stuck in a retry loop is a perfectly well-behaved customer of this architecture, provisioning nodes, reading segments, billing seconds. The architecture cannot tell exploration from pathology, because from the storage layer they are the same access pattern.
Table stakes move fast
Put the three announcements of the last ten days side by side and the pattern is hard to miss. Continuum pools thousands of scale-to-zero virtual clusters because agents multiply databases. Neon is folding realtime sync into the platform because agents need fresh state pushed at them. AlloyDB now serves agents from isolated ephemeral Postgres because agents multiply reads. Different engines, one conclusion: elastic, isolated, agent-facing database capacity is becoming something the platform simply includes, the way connection pooling and read replicas did.
When every serious platform includes it, it stops being a differentiator and starts being a floor. What sits above the floor is the part no storage architecture can absorb: whether the agent's query plan is stable, whose budget its reads land on, what the data it read actually means, and how its intended write gets reviewed into production. The vendors are converging on making agent access cheap and harmless. The open question they are all leaving on the table is making it correct and accountable.
Where Datapace fits
AlloyDB's architecture answers the infrastructure question, and for estates on Google Cloud it answers it well. Datapace works on the layer that stays open once the reads are fast and isolated: what those reads mean and what an agent is entitled to do with them. It builds the context layer between your databases and your AI, with meaning resolved and validated by the people who own the data, workload evidence alongside it, and a policy gate over what an agent may access and execute, served over MCP. If your agents are about to get very fast read access to production, the next conversation is about what they should be reading. Book a call if you are working through that.
Sources
- Google Cloud Blog, AlloyDB delivers PostgreSQL for agents, Raj Pai and Sujatha Mandava, September 24, 2026 (preview status, read-only access, capabilities list, billing model).
- Google Cloud Blog, A new, no-compromises database architecture for the agentic era, Amit Ganesh and Sailesh Krishnamurthy, September 24, 2026 (three tenets, Colossus segments, microVM pool, MCP, benchmark figures, competitor test, alternative-architecture comparison).
- Cockroach Labs, Cockroach Continuum: the Agentic Database Cloud, Spencer Kimball, September 15, 2026 (launch date and positioning).
- Neon, Electrifying Neon: building the realtime backend, James Arthur, September 24, 2026 (realtime sync engine in development, agents framing).