Google Cloud announced on October 2, 2026 the general availability of Spanner queues, a native transactional messaging capability built into its Spanner database and aimed at AI agent workloads. The company said creating a message is simply another write inside an existing Spanner transaction.
What Google announced
In a post by product manager Nitin Sagar and engineering manager Matthew Mucklo, Google Cloud said: "Today, we are excited to announce the general availability of Spanner queues: native transactional messaging embedded directly within Spanner."
According to the company, an agent's state change and its intended downstream actions either commit together atomically or fail completely. Google said that avoids the situation where a database update succeeds but the action dispatch fails, or the message dispatch succeeds while the state transaction rolls back.
Google said that without such a mechanism, developers are forced to build complex outbox patterns, idempotency layers and reconciliation workers, which it described as a heavy reliability tax on agentic architecture.
Capabilities the company describes
Google listed atomic enqueueing inside a single read-write transaction, backed by what it called Spanner's strict serializability and global external consistency. It said queue messages "can be dispatched immediately upon commit or scheduled for future delivery", supporting delayed retries, scheduled check-ins or SLA escalation timers without external cron schedulers or polling infrastructure.
On delivery semantics, the company said: "We guarantee at-least-once delivery and at-most-once ACK, enabling you to achieve exactly-once processing." It also said in-flight workloads, task backlogs and agent execution history can be inspected with standard SQL queries over queue tables.
Beyond AI agents, Google said Spanner queues can serve event-driven architectures such as real-time activity feeds, live updates in news publishing, retail order and inventory workflows, and asynchronous task processing and transaction notifications in financial services.
How it works, per Google
Queues are defined as first-class relational structures using GoogleSQL, with a CREATE QUEUE statement that Google's example interleaves in a parent Orders table. Scheduled messages use a system DeliverTime column to defer visibility, and a pending task can be cancelled with a standard SQL DELETE in the same transaction that updates business state.
Workers consume tasks with the RECEIVE_<QueueName> table-valued function over a streaming SQL connection (ExecuteStreamingSql). Google said Spanner automatically manages message leases, returning a unique SpannerLeaseToken and expiration timestamp with each leased task, and that workers can extend ownership using RENEWLEASE_<QueueName> for long-running agent execution.
The company recommended using ASSERT_ROWS_MODIFIED 1 when acknowledging a message by deleting it, saying it protects against lease-expiration races: if another worker already processed and deleted the task, the statement throws a statement-level error that applications can catch and abort, preventing stale workers from overwriting newer database state.
How it differs from change streams
Google said Spanner change streams are designed for continuous change data capture and data streaming to downstream analytics or storage, while Spanner queues are explicitly designed for transactional task orchestration with native message leases, scheduled deliveries, SQL-based pulling and atomic acknowledgments inside read-write transactions.
The company pointed developers to a Spanner 90-day free trial and its public documentation to create a queue table.
What to do
- Define a queue with a CREATE QUEUE statement in GoogleSQL, then insert messages inside the same read-write transaction that updates your business tables, as Google's example shows.
- To delay a message, populate the system DeliverTime column; to cancel a scheduled task, delete the queue row in the same transaction that updates state.
- Consume tasks with the RECEIVE_<QueueName> function over a streaming SQL connection, and call RENEWLEASE_<QueueName> if processing runs longer than the lease window.
- Acknowledge a message by deleting the queue row inside a transaction and use ASSERT_ROWS_MODIFIED 1, which Google says surfaces an error if another worker already handled the task so the transaction can be aborted.
- Google suggests signing up for the Spanner 90-day free trial and consulting its public documentation to create a queue table.
Key facts and where they come from
- Spanner queues is generally available as native transactional messaging inside Spanner.
Today, we are excited to announce the general availability of Spanner queues: native transactional messaging embedded directly within Spanner.
- Google claims at-least-once delivery and at-most-once acknowledgment, enabling exactly-once processing.
We guarantee at-least-once delivery and at-most-once ACK, enabling you to achieve exactly-once processing.
- Messages can be delivered on commit or scheduled for later.
Queue messages can be dispatched immediately upon commit or scheduled for future delivery.
- Consumption uses a RECEIVE table-valued function over streaming SQL.
Downstream agent workers consume tasks using the RECEIVE_<QueueName> table-valued function (TVF) over a streaming SQL connection (ExecuteStreamingSql).
- Spanner handles leases and issues a lease token per task.
Spanner automatically manages message leases, returning a unique SpannerLeaseToken and expiration timestamp with each leased task
- Change streams remain aimed at CDC and analytics, not task orchestration.
Spanner change streams are designed for continuous change data capture (CDC) and data streaming to downstream analytics or storage.
- Google points developers to a 90-day free trial.
Sign up for the Spanner 90-day free trial