The System Map vs. One Rider's Journey: Global vs. Local Graph Queries

Opening Scene

Some questions about a transit system genuinely require seeing the whole network at once: which stations are the most heavily connected hubs across the entire system, or how many distinct clusters of interconnected lines actually exist. Other questions only ever need to trace one specific rider’s path: how do I get from my current station to my destination. Answering the first kind of question by tracing individual routes one at a time would be absurdly inefficient. Answering the second kind by analyzing the entire network’s global structure would be needless overkill.

Global and local graph queries demand this exact same genuinely different approach.

In Plain English

A local query starts from one or a few specific nodes and explores outward a bounded distance — traversal (Article 5) and shortest path (Article 6) are both fundamentally local operations. A global query analyzes the graph’s entire structure at once — computing centrality (Article 14) or detecting communities (Article 15) requires considering the whole graph, or at least a very large portion of it, not just a small neighborhood around a starting point.

The Old Way

Recognizing which category a given question actually falls into has always been essential to querying a graph efficiently, since the two categories have genuinely different performance characteristics:

• Local queries scale with the size of the neighborhood explored, not the size of the entire graph, meaning they generally stay fast even on a very large graph, as long as the actual exploration stays reasonably bounded.
• Global queries scale with the size of the entire graph, or a very large portion of it, meaning they’re inherently more expensive and often need to be run periodically as a batch computation rather than recalculated fresh for every single request.
• Confusing the two categories is a genuine, common design mistake: attempting to answer a fundamentally global question with a local, bounded-traversal approach produces an incomplete or misleading answer, while running an expensive global computation for a question that only actually needed a local answer wastes real resources.

Getting this right has always meant correctly classifying a question as genuinely local or global before choosing how to answer it, rather than defaulting to one approach regardless of the question’s real scope.

What’s Changing (and Why AI Is the Reason)

1. AI-assisted query classification can analyze a natural-language question and correctly determine whether it’s genuinely local or global in scope, informing the appropriate underlying query strategy automatically. Rather than a developer needing to manually recognize this distinction for every query, AI-assisted analysis of a question’s actual intent can route it correctly, avoiding both the incomplete-answer and wasted-resource mistakes covered above.
2. AI-assisted precomputation scheduling can identify which global graph metrics are worth calculating proactively, on a regular schedule, versus which should be computed on demand, balancing the real cost of global computation against how urgently fresh results are actually needed. This directly parallels the aggregate table precomputation theme covered in this site’s dimensional-modelling topic, applied here specifically to global graph analytics.
3. AI agents need to correctly distinguish local from global questions to generate efficient, appropriately-scoped graph queries, since an agent that doesn’t recognize a question’s genuine scope risks either an incomplete local answer to a global question or an unnecessarily expensive global computation for a genuinely local one. Clear architectural separation between local and global query paths helps an agent route correctly rather than defaulting to one approach regardless of actual need.

The Metaphor, Fully Extended

Subway Element	Global vs. Local Query Concept
Tracing one specific rider’s path from their current station to their destination	A local query, exploring outward a bounded distance from a starting node
Identifying which stations are the most heavily connected hubs across the entire system	A global query, analyzing the graph’s entire structure at once
A route-planning app staying fast regardless of network size, since it only explores a bounded area	Local queries scaling with neighborhood size, not the size of the entire graph
A citywide transit report only recalculated periodically, since analyzing the whole network is genuinely expensive	Global queries often run as periodic batch computations rather than fresh for every request
A route-planning assistant correctly recognizing “what’s the fastest way there” as a local question versus “what’s the most connected station” as a global one	AI-assisted query classification correctly routing a question to the appropriate local or global strategy

Quick Recap

• Local queries explore outward a bounded distance from a starting node, while global queries analyze the graph’s entire structure, and the two have genuinely different performance characteristics.
• Local queries scale with neighborhood size, staying fast even on large graphs, while global queries scale with the entire graph and are often run as periodic batch computations.
• AI-assisted query classification can correctly route questions to the appropriate strategy, and AI-assisted precomputation scheduling can balance the cost of global computation against freshness needs.
• AI agents need to correctly distinguish local from global questions to generate efficient, appropriately-scoped queries rather than defaulting to one approach regardless of actual need.

Where This Fits in the Series

Article 8 covered how schema actually works in a graph. This article covered the difference between the system map and one rider’s journey. Article 10 looks at express lines and local stops — indexing and traversal performance.