Spanner Graph Algorithms: Graph Intelligence in a Relational Database
Google Cloud announced Spanner Graph algorithms in preview on June 3, 2026, adding a suite of built-in graph computation primitives directly to the Spanner database engine. This matters because it eliminates a common architectural pattern where teams extract graph data from Spanner into a separate graph database — Neo4j, Amazon Neptune, or a custom pipeline — just to run PageRank or community detection, then reconcile results back into the transactional store.
The algorithm catalog covers the three core domains that appear in real production graph workloads. Centrality algorithms include betweenness centrality, closeness centrality, and PageRank, enabling ranking of nodes by influence or connectivity. Community detection algorithms include label propagation, modularity clustering, correlation clustering, weakly connected components, and a clique aggregator — the collection that maps cleanly onto fraud ring detection and entity resolution. Similarity and path-finding algorithms cover Jaccard similarity, cosine similarity, common neighbors, total neighbors, and set-to-set shortest paths, which are the building blocks for recommendation systems and supply chain resilience analysis.
Developers invoke algorithms using the ISO Graph Query Language (GQL) CALL syntax, which means the algorithms compose naturally with existing Spanner Graph queries and can be chained. Results write back to Spanner Graph or to Cloud Storage, so a fraud detection pipeline can run ModularityClustering to identify candidate fraud communities, then join those cluster assignments against transaction records in the same database without an export/import cycle. The algorithms run on Spanner's infrastructure, so they inherit Spanner's horizontal scaling and strong consistency guarantees — the cluster assignments you get reflect the committed state of the graph, not a snapshot from a secondary replica.
Availability is currently limited to Enterprise and Enterprise+ editions of Spanner, and the feature is in preview. Teams running on Standard or Business Critical editions will need to upgrade before they can use graph algorithms. A codelab is available for hands-on exploration, and the GQL documentation covers the full parameter surface for each algorithm family.
Read more — Google Cloud Blog
BigQuery-to-Spanner Real-Time Streaming Reaches GA
Google Cloud reached general availability for continuous queries that stream data from BigQuery to Spanner in real time, closing a long-standing gap in the Google Cloud data platform story. Before this feature, teams that wanted Spanner to serve low-latency lookups on BigQuery-computed aggregates — fraud risk scores, personalisation signals, feature vectors — had to engineer custom pipelines using Dataflow or Pub/Sub. Those pipelines work but add operational surface area and introduce replication lag that can range from seconds to minutes depending on batch size and infrastructure.
The continuous query feature lets developers express the streaming transformation as a standard BigQuery SQL statement. The query runs persistently, processing new BigQuery events as they arrive and writing results directly into Spanner rows. Because Spanner serves single-digit millisecond reads at scale, the downstream applications that query those rows get latency characteristics that a BatchQL-then-export pipeline cannot match. The typical use cases are real-time fraud scoring (computed aggregate features updated as transactions land in BigQuery, served by Spanner at checkout time), live recommendation signals, and operational dashboards that need sub-second freshness without sacrificing transactional consistency on the serving side.
General availability means the feature is now backed by Google Cloud SLAs and production support. Teams that evaluated the feature during the preview period can migrate without renegotiating the support tier. The pricing model bills on the number of slot-hours consumed by the continuous query plus standard Spanner write costs, so teams should benchmark against their expected event throughput before moving production workloads — high-cardinality event streams that write a large number of Spanner rows per second will accumulate costs faster than sparse analytical aggregations.
Read more — Google Cloud Documentation
