Google wants databases to work for AI agents. Its new data cloud still has a permissions problem to solve

An enterprise AI agent may have permission to answer a question yet lack a trustworthy route to the underlying numbers. It can find one revenue table but miss the definition of revenue, combine data from incompatible periods, or retrieve a document that its user was never authorised to see. Such failures are not solved simply by installing a smarter language model. They arise in the layer connecting information, organisational rules and computation. Google Cloud's 4 November database announcements concentrate on that layer.[1]

The company presented additions to what it calls the Agentic Data Cloud, including cross-cloud access to Apache Iceberg data, richer catalogue discovery and developments in AlloyDB and Spanner. The commercial proposition is that customers should not have to move every dataset into one proprietary store before agents can use it. Instead, applications would query governed information across data systems, with metadata providing the agent enough context to choose relevant records.[1]

Making data reachable is not making it correct

Apache Iceberg is an open table format used for large analytical datasets. Google says its connections let customers access compatible Iceberg data across major clouds and avoid certain variable data-egress charges in the particular cross-cloud access path it describes. That should not be read as a universal pledge that all traffic between AWS, Azure and Google Cloud is free. Storage, processing, networking, query and service costs can still apply according to product and contract.[1]

The practical attraction is understandable. A multinational company might maintain customer records in one region, logs in a second cloud and finance data in a central warehouse. Physically copying every record for each new application can introduce delay, security review and recurring bills. Access through a common analytical interface may simplify that arrangement. But joining the datasets still depends on data freshness, compatible identifiers, consistent accounting definitions and enforceable data residency rules.[1]

Google cites Delivery Hero's talabat operation reporting roughly 40% lower data movement costs in a relevant deployment. This is an attributed customer result. The announcement does not establish that another company with different cloud contracts and data volumes should expect the same percentage or even a saving at all.[1]

The catalogue becomes part of the agent's reasoning

Google says its Knowledge Catalog improved retrieval accuracy by about four times on an internal evaluation while cutting latency by approximately one third and using about three-quarters fewer tokens. Those are impressive relative improvements, but the article does not publish an independent head-to-head comparison across representative external corporate data estates. An improvement in a retrieval metric also is not automatically an improvement in factual correctness of the completed business answer.[1]

The underlying challenge is that an agent needs semantic information, not just column names. A column called `amount` may represent an invoice total before tax, a settled payment after refunds or a forecast. Metadata must define units, time frames, applicable users and lineage. Without that, faster retrieval can deliver the wrong number with greater confidence. The catalogue should also respect access permissions throughout discovery, reasoning and the final answer, rather than revealing protected facts through a summary.[1]

Databases are becoming services for action

Other updates extend the infrastructure available to developers. Google describes Spanner Omni moving to general availability, while new AlloyDB features and a smaller AlloyDB Express option target development and distributed use. The company highlights selected performance gains for analytical queries that read Iceberg data; an 'up to' result on a particular workload is not an all-query performance guarantee.[1]

These services matter because a software agent may ask a sequence of questions, change a workflow, update a record and then recheck the result. That is a harder governance task than answering one dashboard query. Each step needs scoped credentials, a transaction or recovery mechanism, an audit trail and, for consequential changes, explicit approval. A useful database connector should be capable of refusing an unauthorised request even when the agent is unusually persuasive about what it wants.[1]

A stronger proof of value

A company evaluating this platform should choose representative questions for which analysts already know the answer. Include ambiguous definitions, late-arriving records, revoked permissions, cross-region restrictions and stale data. Measure not merely query speed, but whether the agent selects the right dataset, cites the correct version and refuses prohibited access. Repeat the test after schemas change. For tasks that can write data, add reversibility and human authorisation checks.[1]

The central advance is an attempt to make information infrastructure legible to AI systems. Whether it works will be decided by the most prosaic details—metadata, lineage, permissions and billing—not by the agent's fluency. A polished answer assembled from the wrong accounting definition is still wrong, no matter how quickly the database returned it.[1]

Report an error or suggest a correction