Use Spanner Graph Algorithms to Query Connected Data

Relational queries work well when you need to retrieve records, join tables, or filter data by specific conditions. But some problems become harder when the answer depends on how thousands or millions of entities are connected.

Consider a payment platform investigating fraud. A suspicious account might transfer money to several accounts, which then transfer funds to other accounts. Looking at each transaction independently may not reveal the larger network. The relationships between accounts can expose patterns that ordinary row-by-row analysis misses.

Google Cloud Spanner Graph combines graph queries with graph algorithms to analyze these relationships. In June 2026, Google Cloud announced a preview of native graph algorithms that let developers calculate node importance, detect communities, measure similarity, and find paths without building a separate graph analytics pipeline. The algorithms are designed to analyze large graphs using dedicated compute resources.

For developers, this creates an opportunity to combine operational data with relationship analysis in a single database environment. However, understanding the graph model, query syntax, algorithm inputs, and preview limitations is essential before using the capability in production.

What Is Spanner Graph?

Spanner Graph extends Google Cloud Spanner with property graph capabilities. A property graph represents information using nodes, edges, and properties.

Nodes represent entities such as customers, accounts, products, or servers.
Edges represent relationships such as transfers, purchases, dependencies, or connections.
Properties store attributes associated with nodes and edges, such as an account status, transaction amount, or connection timestamp.

For example, a payment network might contain three accounts connected by transfers:

Account A ──Transfer──> Account B
Account B ──Transfer──> Account C
Account A ──Transfer──> Account C

A graph query can traverse these relationships to identify reachable accounts or find paths between entities. A graph algorithm can go further by calculating which accounts are structurally important or which accounts belong to closely connected communities.

Spanner Graph uses Graph Query Language (GQL) to express graph patterns and supports integration with Spanner's relational data capabilities. This allows applications to analyze connected information without necessarily copying it into a separate graph database.

What Graph Algorithms Are Available?

Spanner Graph's algorithm catalog covers four major categories: centrality, clustering, similarity, and path finding.

Algorithm category	What it analyzes	Example use case
Centrality	Structural importance of nodes	Identify influential accounts or critical network components
Clustering	Groups of densely connected entities	Discover potential fraud rings or customer communities
Similarity	How alike two nodes are based on their connections	Recommend products or identify related accounts
Path finding	Routes and distances between nodes	Trace transaction flows or investigate network dependencies

The categories solve different problems. A node with many connections is not necessarily part of a suspicious community, and two similar nodes are not necessarily connected by the shortest path.

Choose an algorithm based on the question the application needs to answer rather than treating graph analysis as a single operation.

1. Centrality: Identify Important Nodes

Centrality algorithms help identify entities that occupy important positions within a network.

Spanner Graph supports algorithms including PageRank, betweenness centrality, and closeness centrality.

PageRank

PageRank estimates the importance of a node based on the structure of incoming connections. Connections from important nodes contribute more to a node's score than connections from less important nodes.

In a payment network, PageRank can help prioritize accounts for investigation when their position within the transaction graph is significant.

A high PageRank score does not prove that an account is fraudulent. It is a structural signal that should be combined with transaction amounts, account history, behavioral indicators, and other evidence.

Betweenness Centrality

Betweenness centrality measures how often a node lies on shortest paths between other pairs of nodes.

This can reveal intermediary accounts that connect otherwise separate parts of a network. In infrastructure analysis, the same concept can identify components that act as bridges between services or network segments.

Closeness Centrality

Closeness centrality measures how near a node is to other reachable nodes based on shortest-path distances. It can help identify entities that can reach much of a network through relatively short paths.

The exact interpretation depends on the graph's direction, connectivity, and weighting rules.

2. Clustering: Discover Communities

Clustering algorithms group nodes according to their connection patterns.

For example, a fraud investigation may start with thousands of accounts and millions of transfers. Community detection can help divide that graph into groups that are more densely connected internally than externally.

Spanner Graph's algorithm catalog includes modularity clustering, correlation clustering, label propagation, weakly connected components, and clique aggregation.

These methods are not interchangeable. Some focus on community structure, while others identify connected components or groups based on different definitions of similarity and connectivity.

A practical investigation might follow this workflow:

Run a community-detection algorithm on the account-transfer graph.
Persist the community identifier for each account.
Query the resulting communities to count previously flagged accounts.
Select communities that need additional investigation.
Run a centrality algorithm on a selected subgraph to prioritize accounts for review.

This approach combines graph algorithms with ordinary graph queries. It also avoids treating a clustering result as a final fraud decision.

3. Similarity: Find Related Entities

Similarity algorithms compare nodes using their neighborhood structures.

Suppose an online marketplace wants to recommend products to customers based on connected purchasing behavior. Two customers who share several product connections may have similar interests, even if their individual purchase histories are not identical.

Spanner Graph supports similarity measures such as:

Jaccard similarity: Compares the number of shared neighbors with the total number of distinct neighbors.
Cosine similarity: Measures similarity using the vectors of neighborhood connections and, where applicable, edge weights.
Common neighbors: Counts shared neighbors between nodes.
Total neighbors: Counts the distinct neighbors associated with either node.

These measures can support recommendation systems, entity resolution, and relationship discovery.

The algorithm does not automatically establish that two entities represent the same real-world person or organization. Identity resolution should combine graph evidence with other attributes and appropriate confidence rules.

4. Path Finding: Trace Connections Between Nodes

Path-finding algorithms identify routes between nodes.

In a supply-chain graph, a path can show how a disruption at one supplier affects downstream facilities. In a payment network, it can reveal a sequence of transfers connecting two accounts.

Spanner Graph includes many-to-many shortest-path analysis. Given a set of source nodes and a set of target nodes, the algorithm calculates shortest paths between the supplied source-target pairs.

Weighted paths can account for edge costs, provided the graph and algorithm satisfy the documented requirements. For example, a network graph might use non-negative edge weights to represent latency or cost.

Shortest path is not necessarily the same as the safest path, the most frequently used path, or the path with the lowest business risk. The meaning of the edge weight determines what the result optimizes.

Running PageRank with Spanner Graph

Spanner Graph algorithms use GQL and an EXPORT DATA statement to persist their results. The following example follows the documented query pattern for calculating PageRank over account nodes and transfer edges.

Assume a graph named FinGraph contains an Account node label and a Transfer edge label.

EXPORT DATA OPTIONS (
    format = 'CLOUD_SPANNER',
    table = 'Account',
    write_mode = 'update_ignore_all'
) AS
GRAPH FinGraph
CALL PageRank(
    max_iterations => 20
)
YIELD node, score
RETURN
    node.id,
    score AS pagerank_score;

This example illustrates the main components:

EXPORT DATA OPTIONS specifies where the algorithm results should be persisted.
GRAPH FinGraph selects the graph being analyzed.
CALL PageRank invokes the algorithm.
max_iterations => 20 configures the maximum number of iterations.
YIELD node, score exposes the algorithm's output.
RETURN selects the node identifier and calculated score.

The example assumes that the graph schema and destination table support the selected output. Review the algorithm's documented input parameters and the export requirements before executing it.

Because the destination is the Account table, the write mode must be selected carefully. The update_ignore_all option is intended to update existing rows while ignoring the other output columns, which is useful when adding a derived property without overwriting unrelated account data. Validate the behavior against the target schema.

The query does not return a conventional result set directly. Its results are persisted according to the export configuration, after which you can inspect the stored values through a separate query.

Running an Algorithm on a Subgraph

Analyzing an entire graph is not always necessary. A fraud investigation might focus on accounts already associated with suspicious transactions.

Spanner Graph allows algorithms to operate on selected graph elements. A MATCH clause can select nodes and edges, while CALL PER() can invoke an algorithm on the resulting working table.

Conceptually, the workflow looks like this:

Identify relevant accounts and transfers
                  |
                  v
       Build a logical subgraph
                  |
                  v
       Run a graph algorithm
                  |
                  v
       Persist calculated results
                  |
                  v
       Query and investigate results

A subgraph can reduce the analysis scope and make the results more relevant to a specific investigation. However, filtering changes the graph being analyzed. Removing connecting nodes or edges may change centrality scores, community membership, and shortest paths.

If you compare results across time, keep the selection criteria consistent or explicitly account for changes in the analyzed graph.

Why Native Graph Algorithms Matter

Graph analysis has traditionally required additional infrastructure in many architectures. A team might export database records, transform them into graph data, load them into an analytics engine, run an algorithm, and send the results back to the application database.

That pipeline introduces operational complexity. It can also mean that the graph being analyzed is older than the latest operational data.

Spanner Graph's integrated approach reduces the need for that custom data movement. Google states that graph algorithms use dedicated compute resources and can analyze graphs with tens of billions of edges in minutes, although actual execution time depends on the algorithm, graph structure, and configuration.

The benefits include:

Less custom ETL work for supported analysis workflows.
A closer relationship between operational graph data and analytical results.
The ability to combine graph algorithms with GQL queries.
A managed execution model for large-scale graph analysis.

These advantages do not mean that every graph workload should move to Spanner Graph. Existing analytics platforms may still be more appropriate for specialized processing, established data-science workflows, or workloads requiring capabilities that are not supported by the algorithm catalog.

Important Limitations and Best Practices

Spanner Graph algorithms are documented as a Preview feature for Spanner Enterprise and Enterprise Plus editions. Preview capabilities can have limited support and are subject to the applicable pre-GA terms.

Before adopting them for a critical application, consider the following practices:

Validate algorithm assumptions. Check whether the algorithm requires a directed or undirected graph, non-negative edge weights, or other specific input properties.
Start with a representative subgraph. Verify the output and understand its meaning before analyzing a larger dataset.
Monitor compute and execution time. Dedicated algorithm resources do not eliminate cost or the need to manage execution.
Treat results as analytical signals. PageRank scores and community labels should support decisions, not replace business rules or human review.
Persist results deliberately. Decide whether results belong in Spanner or Cloud Storage and confirm the required permissions and output schema.
Review feature maturity. Confirm the current release stage, supported editions, and operational restrictions before relying on the algorithms in production.

Conclusion

Spanner Graph algorithms extend graph queries beyond simple relationship traversal. Centrality can help identify important nodes, clustering can reveal communities, similarity can uncover related entities, and path finding can trace connections through a network.

The practical advantage is the ability to combine these algorithms with graph queries and existing Spanner data without automatically building a separate analytics pipeline. For fraud investigation, recommendations, entity resolution, and network analysis, that can simplify the path from connected data to useful insights.

Start with a specific question, select the algorithm that matches it, validate the graph assumptions, and examine the persisted results before integrating them into application decisions. That approach makes graph analytics more useful and reduces the risk of interpreting an algorithm's output as something it does not actually prove.