Imagine this scenario: it is 10:42 AM, right in the middle of an outbound peak, and an AI agent is asked a reasonable question: "Why are a specific customer's urgent orders accumulating 'short picks'?"
Let’s assume the agent is prohibited from updating stock, releasing work, or changing assignments; it operates in read-only mode, so it seems safe.
However, answering the question might require far more than a simple lookup: the agent reviews orders, inventory snapshots, location status, replenishment history, pending movements, recent exceptions, and so on. Now imagine it revises its hypothesis, repeats part of the analysis, and asks two or more specialist agents to investigate it in parallel. Each query is authorized, yet the resulting activity still competes with the core system, which is busy confirming picks, closing containers, loading trailers, and handling a myriad of other operational scenarios. As you can see, this leads to a real-world management scenario that extends far beyond the application itself, its database, or server resources.
That is why, after seeing a recent post from Google, their new AlloyDB architecture caught my attention. The key takeaway isn't simply that agents can query data in real time; it is that permissions and workload isolation address distinct operational risks.
Read-only is not a service-level guarantee
In most discussions about operational AI and its architecture, read-only access is treated as the safe starting point. That is correct in one narrow sense: a user or agent that cannot write should not be able to change the system of record directly.
However, a database also has finite computing power, memory, I/O bandwidth, connection capacity, and concurrency limits. A poorly designed dashboard can impair performance without altering a single row; for instance, a simple agent might perform the same task at a different scale because a seemingly straightforward objective, such as a query, could trigger a lengthy reasoning loop involving numerous searches, joins, and attempts.
Read-only therefore answers one question: what may this agent change? But it doesn't answer another: what resources may this agent consume while deciding?
For a Warehouse Management System (WMS), this distinction is operational and potentially hazardous. A delayed analytical response is inconvenient and impractical; a late inventory confirmation during the shipping cutoff can disrupt service and ultimately affect the customer (something no one who works, or has worked, in this sector enjoys dealing with haha).
An agent can respect every permission it has and still create an unacceptable operational impact.
What Google actually announced
In late September 2026, Google announced PostgreSQL for agents in AlloyDB as a public preview. The architecture gives agents up-to-the-second, read-only access to production data through ephemeral PostgreSQL instances that remain separate from the primary, standby and conventional read-replica infrastructure.
Google describes each agent node as a full PostgreSQL engine running inside an isolated microVM. These nodes can utilize indexes, SQL, vector search, full-text search, and spatial search, and then scale down to zero once the reasoning workload concludes (honestly, a rather interesting feature). This same architecture can connect operational data with BigQuery and Spark for lakehouse analytics.
The distinction between shared data and shared compute is the most valuable part of the announcement. Agents may need the latest operational state, but that does not mean their unpredictable query bursts should share the resources used to run the business.
It is important to note that this is a preliminary version, not a generally available feature backed by years of proven performance in production. The documentation places it under Google’s Pre-GA terms, and the published performance figures come from Google’s own tests.
One investigation can become hundreds of queries
Imagine an agent investigating a pattern of incomplete orders within a priority group. It might start by looking at the allocated quantity versus available stock. Then, discovering that the affected units passed through multiple LPN IDs, it retrieves the movement history. It compares confirmation timestamps against replenishment tasks, checks for blocked locations, and searches for similar incidents in unstructured operational notes.
A human analyst would typically make an explicit decision about which query to run next, but an agent can generate that sequence dynamically. If it delegates parts of the investigation to other agents, retries slow requests, or compares multiple hypotheses, the number of database operations can escalate very quickly...
In reality, none of these behaviors is necessarily incorrect. In fact, they can lead to better diagnostics; however, the problem lies in the fact that the workload is difficult to predict based solely on the user's "initial problem or query" until that query is actually executed.
This is a recurring architectural pattern in agent-based systems: the interface presents a single request, while the infrastructure follows a branching, dynamic workflow.
The WMS has more important work to do
During peak warehouse activity, the operational database does not function as an analytics environment. Its role is to maintain shared information used by scanners and terminals, automation systems, supervisors, APIs handling ingress/egress messages, third-party vendors, external systems, etc. Consider routine activities such as order confirmation, stock reservation, creation of replenishment requests, task assignment, container status updates, and shipment logging. While these transactions are generally small, latency issues directly impact warehouse operations; if a confirmation takes longer than expected, the operator is forced to wait. Now, imagine a scenario where multiple interdependent updates pile up in the queue, causing a cascading delay as various agents attempt to access the tables driving those activities.
This is precisely where I would distinguish between two types of controls:
- Authority controls determine which tables, rows, fields and actions the agent can access.
- Resource controls determine where its queries execute, how much concurrency they receive, how long they may run and whether they can affect production capacity.
Permissions and resource isolation protect different aspects: while access based on the principle of least privilege prevents an agent from viewing or modifying data it does not need, workload isolation prevents even authorized queries from consuming resources required for active WMS transactions. Therefore, a production-ready design requires both elements: restricted data access and separate, bounded computing resources.
Fresh data does not have to mean shared compute
Google states that agent nodes can read the latest operational state while remaining physically separate from the production cluster in terms of compute, networking, and storage. In Google’s test, the system scaled from one to 1,000 agent nodes and reached approximately three million queries per second, with no measurable impact on primary-cluster performance (though I admit I would also like to see detailed resource utilisation across the servers involved, haha).
Although this is an impressive vendor-reported result, it does not represent a universal benchmark for Warehouse Management Systems (WMS). Factors such as workload structure, data models, indexing, regions, integrations, and behavior during activity spikes play a significant role. I view this figure as a validation of the design goal rather than a guarantee of capacity for different environments or the day-to-day operations of many companies.
The lakehouse connection adds another useful layer. An operational investigation rarely needs only the current WMS state. It may also need historical demand, carrier events, labour data or long-term exception patterns. Combining recent transactions with that context can reduce the pressure to duplicate every analytical dataset inside the operational system.
However, a lakehouse does not automatically resolve semantic issues; continuing with our example, the agent still needs to understand which inventory status allows for allocation, which timestamp represents the business event, or whether two systems use the same definition for an order, shipment, or exception.
My perspective on a WMS-managed warehouse
Before approving an architecture like this, I would build a controlled test around an operational scenario rather than a generic query benchmark.
For example, run a realistic wave and dispatch workload while a growing number of agents investigate inventory discrepancies. Then measure:
- p95 and p99 latency for the WMS transactions that matter on the floor;
- freshness lag between the production event and the state visible to the agent;
- concurrent agent queries, retries and abandoned reasoning branches;
- behaviour when an index is missing or a query plan changes;
- isolation during sudden peaks rather than only steady load;
- query cost per completed and validated investigation;
- whether every answer can be traced back to the data and time window used.
I would also test the failure boundary. What happens when the isolated agent pool is unavailable? Does the warehouse continue normally? Does the investigation pause cleanly, or does another component fall back to querying the primary system?
Isolation is valuable only if the fallback path preserves it.
Where the evidence stops and engineering begins
Google's announcement includes a commercial testimonial from Manhattan Associates describing inventory and order analysis with sub-second data freshness while transactional processing remains untouched. That connection makes the architecture especially relevant to supply chain, but it should be read for what it is: a customer statement published by Google, not an independent evaluation of a particular WMS implementation.
The broader lesson does not hinge on the choice of AlloyDB. As agents gain greater capabilities, the number and nature of the queries underlying a business request become less predictable. Providing up-to-date operational data to those agents is useful, but linking their reasoning directly to the resources that keep operations running can also lead to unexpected outcomes.
For me, the architectural principle is simple: allow agents to learn from the live operation without allowing their curiosity to become part of the operation's critical path.
---
Sources: Google Cloud, AlloyDB delivers PostgreSQL for agents: Real-time data at agent scale, with full workload isolation · Google Cloud, A new, no-compromises database architecture for the agentic era · Google Cloud Documentation, PostgreSQL for agents in AlloyDB