We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Database Types & Storage
A database built for storing and querying relationships between entities. Nodes are entities, edges are relationships. Neo4j is the most popular.
In short
A graph database is a database that stores data as nodes (entities) connected by edges (relationships), so following a connection from one record to another is a direct pointer hop instead of a join. This makes it fast for queries that traverse many hops, like finding friends of friends, fraud rings, or recommendation paths, where relational databases would need expensive repeated joins.
In short
A graph database is a database that stores data as nodes (entities) connected by edges (relationships), so following a connection from one record to another is a direct pointer hop instead of a join. This makes it fast for queries that traverse many hops, like finding friends of friends, fraud rings, or recommendation paths, where relational databases would need expensive repeated joins.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Graph Database across a run of lessons, not one page. These 4 alone are about 70 minutes of step-by-step reading, every one with a quiz.
Databases that store relationships as native citizens, powering social networks, fraud detection, and recommendation engines.
Nodes arranged in a circle, each replicating to the next, clean but fragile.
A dedicated physical network link between your data center and AWS, bypassing the internet entirely.
Running computation at the network edge, closer to users, instead of in centralized cloud data centers.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Graph Databasespay once,
yours for life
A graph database models data the way you would draw it on a whiteboard. Each thing is a node: a person, an account, a product, a server. Each connection between two things is an edge: FOLLOWS, PAID, BOUGHT, DEPENDS_ON. Both nodes and edges can carry properties, so a Person node holds name and age, and a PAID edge holds amount and timestamp.
The defining feature is how relationships are stored. In a relational database, a relationship between two rows is implied by matching a foreign key, and you reconstruct it at query time with a JOIN. In a native graph database, each edge is stored physically next to the nodes it connects, with a direct pointer. The engine calls this index-free adjacency: to walk from a node to its neighbors, it follows pointers rather than scanning or indexing a join table.
Most graph databases use one of two models. The property graph model (Neo4j, Amazon Neptune, Memgraph) uses labeled nodes and edges with key-value properties. The RDF triple model (used in semantic web and knowledge graphs) stores facts as subject-predicate-object triples. Property graphs dominate application development today.
The reason graph databases are fast for connected data is constant-time hops. Finding a node's neighbors costs roughly the same whether the database holds a thousand nodes or a billion, because the engine already knows where that node's edges live. Cost scales with the size of the result you walk, not the size of the whole table.
Compare a query like find all friends of friends. In SQL you join the friendships table to itself, and each extra hop adds another self-join that the planner has to optimize, often touching far more rows than you need. A graph query expresses the same thing as a short pattern, for example MATCH (me)-[:FRIEND]->()-[:FRIEND]->(fof), and the engine simply walks two edges out from the starting node.
Queries are written in a pattern language. Cypher (Neo4j, and the closely related ISO standard GQL) and Gremlin (Apache TinkerPop) are the common ones. You describe the shape of the subgraph you want, like (user)-[:VIEWED]->(product)<-[:VIEWED]-(other)-[:BOUGHT]->(rec), and the database returns matching paths.
Reach for a graph database when relationships are the point of the query, not an afterthought. Good fits: social networks (friends of friends, mutual connections), fraud detection (rings of accounts sharing a device or card), recommendation engines (people who bought this also bought), network and IT topology (what breaks if this server fails), identity and access graphs, and knowledge graphs that power search and AI retrieval.
The trade-off is that graph databases are not a general replacement for relational ones. They are weaker at heavy aggregate analytics over whole tables (sum every order this quarter), and most do not match the transactional throughput and tooling maturity of Postgres or MySQL for plain CRUD. Scaling writes horizontally is harder because edges cross machines, so sharding a graph is a real engineering problem.
A practical pattern is to keep your system of record in a relational or document store and use the graph database for the connected slice that needs traversal. Many teams sync a subset of data into a graph for specific features rather than running everything on it.
Picture a payments company watching for fraud. Each signup creates a Person node. Edges connect people to the devices, phone numbers, cards, and shipping addresses they use. A single fraudster is hard to spot, but a ring is not: twenty accounts that all funnel back to the same two devices and one card form a tight, dense cluster in the graph.
With a relational schema you would write a tangle of self-joins to find accounts two and three hops away that share identifiers, and it gets slow as the data grows. In a graph database you run a short traversal from a flagged account outward and look for clusters with suspicious shared nodes, returning results in milliseconds even over hundreds of millions of accounts.
This is exactly why companies like PayPal and many banks run graph engines for fraud and anti-money-laundering. The same shape of query, following connections a few hops out from a starting point, also powers LinkedIn degree-of-connection counts and Netflix-style recommendations.
Neo4j
The most widely used graph database, with the Cypher query language; powers fraud detection, recommendations, and knowledge graphs across enterprises.
Amazon Neptune
AWS managed graph service supporting both property graph (Gremlin) and RDF (SPARQL) for identity graphs and knowledge graphs.
Models the professional network as a graph to compute degrees of connection and people-you-may-know suggestions.
PayPal
Uses graph traversal to detect fraud rings by spotting clusters of accounts sharing devices, cards, and addresses.
A relational database stores relationships as foreign keys and rebuilds them at query time with JOINs, which gets expensive across many hops. A graph database stores each relationship as a direct pointer between records, so traversing connections is fast and the cost depends on how much of the graph you walk, not the total table size.
No. Neo4j is the most popular, but alternatives include Amazon Neptune, Memgraph, ArangoDB, TigerGraph, and JanusGraph. Some general-purpose databases also add graph features, and the RDF/triple-store world (like GraphDB and Blazegraph) handles semantic graphs.
Avoid it as your only store when most queries are simple CRUD or large aggregate analytics over whole tables, where relational and columnar databases are stronger and more mature. Graph databases shine for highly connected data and multi-hop traversal, so a common pattern is to keep a relational system of record and use a graph for the connected features that need it.
Property graph databases mostly use Cypher (Neo4j) or Gremlin (Apache TinkerPop). Cypher is now the basis of the ISO standard GQL. RDF triple stores use SPARQL. You describe the pattern of nodes and edges you want, and the engine returns matching paths.
It means each node directly references its connected edges and neighbors in storage, so finding a node's neighbors is a pointer hop rather than an index lookup or join-table scan. This is why hop cost stays roughly constant as the dataset grows, which is the core performance advantage of native graph databases.
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
SQL
Structured Query Language for managing relational databases. Tables, rows, columns, and powerful joins to query related data.
Document Database
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
Redis
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
Memcached
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
Key-Value Store
The simplest NoSQL model: store data as key-value pairs. Blazing fast lookups by key. Redis, DynamoDB, and etcd are key-value stores.
This page explains the idea. The "Graph Databases" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Graph Databases lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Graph Database in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
