Google 替分散式資料庫 Spanner 加入原生訊息佇列功能。應用程式往後可以在同一筆資料庫交易中，同時完成資料更新與任務派送，兩者要麼一起成功、要麼一起取消，避免資料已經改了、後續工作卻沒執行的尷尬。
這項功能主要是為 AI 代理這類應用設計。AI 代理執行退款、調整庫存，或把工作交給其他代理時，通常不只修改資料庫，還要把接下來要做的事送進訊息佇列。
過去這兩個動作由不同系統處理，狀態可能對不上。可能發生資料已經更新，工作卻沒有送出；也可能工作已經送出，資料庫的變更最後卻失敗了。開發團隊還得自己收拾這種不一致。
Spanner 把訊息佇列直接放進資料庫後，新增任務可以和其他資料異動放在同一筆交易裡。以核准退款為例，代理可以同時把訂單狀態改為「已核准」，並加入實際執行退款的工作。
整筆交易成功提交，訂單狀態和退款任務才會一起生效；交易失敗，兩者都不會生效。可靠性由資料庫層級直接保證。
負責執行工作的程式，可以透過 SQL 從佇列取得任務，做完後再更新處理結果並移除訊息。系統也支援排定任務稍後執行，例如等主管核准一段時間後再自動升級處理。
如果 AI 代理需要較長時間呼叫外部服務或完成多步驟工作，處理端也可以延長持有任務的時間，避免任務被提早釋放。
在訊息可靠性上，Spanner 保證訊息至少送達一次。碰到網路或執行失敗時，同一項工作仍可能再次出現，同一則訊息最多只會被成功確認一次。
這也代表，退款、付款這類不能重複執行的動作，應用程式仍要自己設計防止重複處理，不能假設所有外部操作都只會執行一次。
從使用場景來看，原生訊息佇列主要用在交易完成後觸發工作、安排稍後執行的任務，以及逐項確認工作完成。既有的變更串流功能則著重持續擷取資料變化，提供給下游分析或其他系統。
這項功能目前提供給 Spanner Enterprise 與 Enterprise Plus 版本的用戶使用。
