Graph database or distributed SQL for identity resolution?

The previous entry on identity resolution proposed that household graphs must transition to incremental updates rather than relying on nightly recomputation [Link to Blog 3]. For engineers who have managed these systems, the next natural question is: why not simply adopt a native graph database for graph operations? The answer depends less on the "graph" label and more on the granular production requirements.

To summarize: while native graph databases are optimized for deep, multi-hop traversals across interconnected data, an identity graph typically requires only one or two hops. The priority for identity resolution is the ability to ingest new edges in milliseconds and perform concurrent joins without triggering a global recomputation. These requirements generally favor a distributed SQL engine  that supports database sharding by a stable key over a specialized traversal store.

What an identity graph actually asks of a database

Categorizing the tasks often grouped as "graph" work reveals three distinct functions. First is ingestion, where new signals link devices to households and establish edges. Second is the point read, which identifies a device's household and retrieves real-time frequency counts across associated screens. Third is the analytical join, used for attribution and calculating audience reach. None of these require deep traversals; the most extensive path typically involves moving from a device to a household followed by its other devices, a mere two hops at most.

Native graph databases are designed for a different profile: complex queries that traverse many hops through dense networks, such as those found in recommendation engines or fraud detection. 

When applied to workloads dominated by one-hop lookups and heavy concurrent aggregations, these engines become an expensive, underutilized resource. The operations that matter most like ingestion and joining are not what these traversal-centric engines were optimized for. This is the same category fit issue we’ve seen throughout the series.

Reframing the Rebuild: A Partitioning Challenge

The restrictive nightly processing window is not an exclusive drawback of graph technology; instead, it's a byproduct of recomputing global structures in batches When resolution is global, any new edge can theoretically alter the entire structure, making full scheduled recomputation the only "safe" approach.

Implementing data sharding effectively severs this coupling. By partitioning the graph (eg,  by household) a new signal linking a device to that household only affects a single partition. As a result, the resolution effort becomes proportional to the size of that one partition rather than the entire global graph. This shifts incremental resolution from a complex research challenge into a standard write operation.

However, household sharding introduces its own complexities. 

Cross-household edges mean some edges will inevitably span multiple shards. While a robust distributed engine can manage these cross-shard cases, they are more costly than local operations. 

The case for distributed SQL in customer identity resolution

Three structural properties typically give distributed SQL the advantage in this category. The main one is the ability to process a transactional write (the incoming edge) and immediately perform an analytical read, such as an attribution join, against the same data without intermediate copying. HTAP provides the cornerstone capability of the initial post and remains a rare feature in native graph databases but a native strength of real-time distributed SQL.

Concurrency serves as the second decider. Identity graphs aren’t only ingestion-heavy. They are read-heavy, supporting the dashboards accessed by thousands of concurrent advertisers as detailed in the fourth post. Infrastructure that already handles this serving load can manage identity joins without additional specialized systems. 

Third is multi-modality. As deterministic identifiers fade, identity resolution increasingly relies on probabilistic matching and embeddings. An engine that stores structured edges, JSON signals, and vectors in one place executes similarity searches alongside standard SQL joins rapidly instead of delayed processing from stitching different data points together. We cover the same consolidation logic presented in the model-focused post.

This does not imply that graph databases are inherently flawed. Instead, it acknowledges that identity resolution at advertising scale is characterized as a one-or-two-hop, write-intensive, and freshness-critical workload. These profiles align more closely with a shardable distributed SQL engine than a traversal-optimized one. The choice then is driven with the actual shape of the work rather than the name of the requirement.

Diagnostic: Graph vs. SQL requirements

A straightforward exercise can determine the appropriate path: define the deepest traversal your production workload truly requires. 

If you are limited to one or two hops and the primary bottlenecks are concurrency and rebuild latency, the issue is fundamentally a partitioning and serving problem, making distributed SQL the better fit. 

On the other hand, if your product relies on five or six hops through a dense network, you have a genuine graph-database workload. 

Most ad platforms eventually find they are treating a one-hop serving problem as a complex graph problem simply because of the terminology used in the beginning.

Returning to the themes of the identity post: the reliance on nightly schedules has outlived its utility, as has the assumption that all graph problems require graph databases. The serving layer approach resolves identity through consolidating the write and the read on fresh data in a single location.