Google Cloud folds message queues into Spanner, where they scale with database compute

Every message in this design is a row in a Spanner table. The capacity to hold and serve those rows comes from the compute instances the customer already runs ^[5][6]. The cost of messaging is therefore part of the cost of the database. Google says event-driven and agent systems no longer need messaging infrastructure layered on top of Spanner ^[7]. Crypto Briefing's report of the announcement does not include a price for queue traffic or a throughput figure. Crypto Briefing's own caveat is that customers will be weighing how costs scale as agent workloads grow ^[8].

The engineering case is narrower. An agent reads state, decides, updates a record and starts the next task, and if the record changes but the follow-up is never queued, the workflow stalls ^[9]. Spanner queues write the message inside the same read-write transaction, so the record and the task commit or roll back together ^[2][3]. Google calls this a "decide-and-act" operation ^[11].

Google's recent Spanner releases all go in one direction. Vector search, graph models, a multi-model expansion and integrations with LangChain and Gemini have been added to the database ^[12], and Spanner Omni arrived on October 1 for more flexible deployment ^[13]. The queues showed up as generally available in release notes on September 17, 15 days before the formal announcement ^[14][1]. Crypto Briefing describes the appeal as one database handling records, relationships, vectors and messages, with less dependence on separately managed services ^[15]. The queue's capacity is set by the database it sits in ^[6].

According to Crypto Briefing, a research summary expects the feature to draw enterprises trying to cut down on disparate systems, potentially lifting database usage and migrations to Google Cloud ^[16]. Compute-linked scaling could cut the other way. A team whose agents generate many more messages than records pays database compute for every one of them ^[6], and at high volume a dedicated broker may come out cheaper. Adoption could also stay confined to low-volume cases where losing a task is expensive. So far one customer has been named: Attio, which Crypto Briefing calls AI-native, endorsed the feature ^[18].

I think consolidation wins where a dropped task costs more than the compute. Order processing and financial transaction notifications are both on Google's list ^[17]. In those workflows, a record updated without its follow-up task means a stalled order or a notice that was never sent ^[9]. The counter-thesis is the bill. If agent-heavy customers like Attio end up running a broker beside Spanner for their high-volume traffic, the consolidation case shrinks to a convenience for small queues.