A fraud team must find rings of accounts connected through shared devices, shared addresses and shared payment cards, often four or five hops apart. Relational queries with many self-joins are timing out. Which database type is designed for this kind of query?

Graph databases model data as nodes (accounts, devices, addresses, cards) and edges (uses, lives at, paid with), and they store edges as direct references between nodes. A traversal from one account through a shared device to another account and onward follows those references hop by hop, so the cost grows with the size of the neighborhood explored rather than with the total size of the tables. That makes multi-hop pattern queries such as fraud rings, recommendation paths and network dependencies practical. A relational design must express each hop as another join, and five-hop self-joins over large tables multiply intermediate results, which is why the existing queries time out. A time-series database is optimized for appending timestamped measurements and aggregating them by time window; it has no native notion of relationships between entities. A column-oriented database accelerates scans over a few columns across many rows, which helps aggregates but not path-finding between linked entities. A key-value store retrieves a value by exact key and cannot traverse from one key to related keys without repeated application-side lookups. Exam caveat: graph databases are not the best choice for bulk aggregates over every row; they shine when relationships are the question. Operational check: model a small sample of accounts and shared identifiers as nodes and edges, then confirm a four-hop path query returns the expected ring.