Graph Databases

Columns count oceans, but fraud hides three hops through shared devices

Wide-column stores ended with quorum arithmetic and tombstones: reads plus writes exceeding three replicas buys strong reads, and deleted data resurrects when a node returns past the hinted-handoff window, which is the bounded time neighbors hold its missed edits. Counting and expiry cover aggregates over time. A fraud check asks for accounts linked to known scammers within three hops through shared devices, addresses, and phone numbers. In relational form each hop is a join, which is a query combining tables, across large tables, and each hop multiplies the intermediate rows before filtering. At depth four the planner, which is the optimizer choosing join order, runs out of good plans and analysts wait.

Precomputing every possible path fails next: paths grow combinatorially with depth, storage explodes, and each new edge invalidates cached answers. A second tempting fix is recursive common table expressions in SQL, which walk hierarchies without a new store, and it fails past modest depth with numbers: at 200 follows per person, three hops materialize 8,000,000 intermediate rows before filtering, so depth-four queries time out while the graph walks only the visited neighborhood in milliseconds. The cost must move from rebuilding connections per query to storing them once.

A graph database, which stores entities as nodes and their typed links as edges with direct pointers between them, keeps connections as stored facts instead of reconstructed joins. Think of a road network where each intersection knows its outgoing roads: one analogy for the whole idea, where a hop follows a pointer at roughly constant cost no matter how many intersections the map holds.

Nodes carry facts while typed edges carry meaning

A node, which is one entity such as a person or device with properties like name and city, is the dot. An edge, which is a directed typed link such as FOLLOWS between two nodes, is the arrow, and its type carries semantics that a generic foreign key cannot express. Properties live on both, so the edge itself can record when the follow happened.

Five joins shrink to three lines once hops become pointer walks

Cypher, which is the declarative query language of the leading graph database where patterns are drawn with parentheses and arrows, states the shape wanted rather than the join order. The engine starts at Alice and follows stored pointers, so each hop costs roughly the same regardless of total graph size, unlike joins whose intermediate results grow with table sizes multiplied.

Graphs earn their keep where connections are the product

The common thread is multi-hop filtering by edge type: the answer depends on paths rather than on attributes of single rows. Social suggestions, fraud constellations, recommendations through shared behavior, shortest routes, entity webs behind assistants, and permission chains through teams and roles all share that shape, where relational indexes on single columns cannot prune the path explosion.

Three graph engines span default, managed, and planet-scale storage

Neo4j, which is the most widely taught graph database with a diagram-like query language and transactional guarantees, is the starting point. Neptune, which is the managed graph service speaking two query languages instead of one, removes server operations at the cost of less control. JanusGraph, which is the open-source graph layer storing its data inside distributed wide-column systems, fits graphs too large for one machine, because it inherits horizontal storage while paying their operational complexity.

Fan-out math shows why depth four belongs to pointer walks

Count a social graph where everyone follows 200 accounts. Two hops from one person reach 200 times 200, which is 40,000 candidates, and three hops reach 8,000,000, because each join materializes its fan-out before filtering, so cost grows with paths explored, roughly exponentially in fan-out times depth. A native graph follows pointers node to node with index-free adjacency, which means each node directly references its neighbors without a global lookup, so cost grows with edges actually traversed and hop three costs about the same as hop one. The summary line is that joins scale with table sizes multiplied while traversals scale with the visited neighborhood, which is why friends-of-friends-who-bought-X times out relationally at depth three and returns in milliseconds on a graph.

Celebrity nodes turn one innocent traversal into a denial-of-service query

Every real graph has supernodes, which are nodes with millions of edges where the average has hundreds. Traversing through one without a limit fans out to millions, holds memory, and starves other queries, which is the graph version of a hot shard. Fraud graphs hit the same wall through shared network addresses and devices linking half the population, and sharding the graph itself turns cut edges, which are relationships spanning machines, into network hops. The working knobs are per-node expansion caps, traversal ordered by rare edge types first for selectivity, per-query depth and time budgets, splitting supernodes by time or edge type, and precomputing their neighborhoods offline. Recursive common table expressions, which are SQL's built-in way to walk hierarchies, cover modest depth and size and should be the start, with the native store earning its place once traversals dominate the hot path.

Shape follows the dominant question across the whole tour: tables guard truth, documents store wholes, columns count oceans, and graphs walk connections past depth three where joins multiply into millions. No single shape covers a real company, because ledgers still need atomic commits while sessions need microsecond keys. Choosing per workload, with each new store priced as a backup story plus an on-call story plus a consistency pipeline, is the final decision.