Graph and network analytics, explained

Most analytics starts with rows: a table of customers, a table of transactions, a table of events. Graph and network analytics starts somewhere different — with the connections between things, treating the relationship itself as the primary object of interest rather than a foreign key that joins two tables together. That shift in perspective matters whenever the question is really about structure: who is connected to whom, how far apart are two nodes, which node sits at the center of a network, and — increasingly — how that structure changes over time.

The questions people ask

A fraud team asks whether a cluster of accounts that don't individually look suspicious form a coordinated ring when viewed together. A social platform asks who the most influential accounts are within a community. A supply-chain analyst asks how many hops separate a finished product from a single point-of-failure supplier. An IT team asks which service, if it went down, would take the most downstream systems with it. All of these are graph questions: they depend on the shape of a network, not on any single row of data in isolation.

The data it runs on

A graph is built from two basic elements: nodes (or vertices) representing entities — people, accounts, products, servers — and edges (or relationships) connecting them, which can carry their own properties (a transaction amount, a timestamp, a relationship type). This "property graph" model is the most common representation and underlies tools like Neo4j and TigerGraph. A second, older representation — RDF triples, queried with SPARQL — is more common in formal knowledge graph and semantic-web work, where relationships need to support logical inference (if A is a subclass of B, and B is a subclass of C, infer A is a subclass of C) rather than just fast traversal.

What makes graph data distinct operationally is that the interesting questions usually require walking multiple hops outward from a starting node — "friends of friends who also follow this account" — a pattern that gets exponentially expensive to compute with repeated joins in a relational database as the number of hops grows, which is the core reason purpose-built graph databases exist.

Core methods and how to read them

Graph analytics is the umbrella term for algorithms that compute properties of a network's structure rather than of any single node in isolation — how connected it is, where the bottlenecks are, which groups cluster together.

Centrality measures rank nodes by their structural importance, and "importance" has several distinct, non-interchangeable definitions: a node with many direct connections (degree centrality) is not necessarily the same node that sits on the most shortest paths between other pairs of nodes (betweenness centrality), and neither is necessarily the node closest to everyone else on average (closeness centrality). Picking the wrong centrality measure for the question at hand is a common source of misleading "most important node" claims.

PageRank, originally built to rank web pages by the pattern of links pointing to them, is the best-known specific centrality algorithm: a node is considered important if it is linked to by other important nodes, computed iteratively. It has been generalized well beyond web search into fraud scoring, recommendation systems and influence ranking on social graphs.

Community detection finds clusters of nodes that are more densely connected to each other than to the rest of the network — the graph equivalent of clustering, used to find organic groups (interest communities, collusion rings, product affinity clusters) that were never explicitly labeled as groups in the source data.

Link prediction estimates the likelihood that an edge should exist between two nodes that aren't currently connected — the mechanism behind "people you may know" and product recommendation features, and also a genuine analytical technique for inferring missing or future relationships from existing network structure.

Organizational network analysis applies these same techniques inward, mapping how communication and collaboration actually flow inside a company (often from calendar, chat or email metadata) rather than how the org chart says they should — frequently surfacing informal hubs and bottlenecks the formal hierarchy doesn't show.

Fraud detection is one of the most common applied uses of all of the above together: individually unremarkable accounts, transactions or claims can reveal a coordinated ring only when centrality, community detection and link analysis are applied to the network connecting them — shared devices, addresses, payment instruments — which is exactly the pattern relational, row-by-row analysis struggles to surface.

How the work is done in practice

The tools in this category split mainly on query language, deployment model and how much scale they're built for. Neo4j is the most established option, using Cypher — the pattern-matching language that also formed the basis of the new ISO GQL graph-query standard — with a free Community edition for self-hosting and a managed AuraDB cloud service billed per GB above a free tier; its Graph Data Science library ships most of the algorithms above out of the box. Amazon Neptune is AWS's fully managed alternative with no self-hosted option, notable for supporting both the property-graph model (via Gremlin or openCypher) and RDF/SPARQL on the same infrastructure, useful for teams who aren't sure yet which model they need. TigerGraph is built around a massively parallel engine specifically for queries that traverse ten or more hops deep — the range where relational joins and some single-node graph databases struggle — using its own GSQL language. Memgraph targets the opposite end of the trade-off: an in-memory, Cypher-compatible engine built for millisecond queries in latency-sensitive use cases like real-time fraud scoring or GraphRAG retrieval for AI applications. ArangoDB takes a multi-model approach, storing graph, document and key-value data in one engine queried with a single language (AQL), aimed at teams who don't want to run a separate document database alongside their graph store.

Common mistakes and misreadings

Picking the wrong centrality measure for the question. "Most important node" is not one calculation — degree, betweenness and closeness centrality answer different questions and can rank the same network completely differently.

Modeling a problem relationally that is really a graph problem. Multi-hop queries ("friends of friends of friends who bought X") tend to degrade badly in a relational database as the number of joins grows; recognizing a graph-shaped question early avoids building something that becomes unworkably slow at scale.

Treating link prediction scores as certainty. A predicted edge is a probability estimate based on structural similarity to existing connections, not a confirmed relationship — using it as ground truth downstream (for example, in a fraud investigation) without a human review step invites false positives.

Ignoring edge properties. Reducing a network to unweighted "connected or not" edges discards information — a $10 transaction and a $10 million transaction are structurally the same edge but very different signals — that most graph databases are built to carry natively.

Confusing a knowledge graph with a property graph. A knowledge graph built for semantic inference (RDF/SPARQL) and a property graph built for fast traversal (Cypher/Gremlin) solve related but different problems, and choosing a tool built for one when you need the other is a common and expensive early mistake.

For a closer look at the databases themselves, see every tool in this category.