What is a graph database?

Concepts · 6 min read

A graph database stores data the way you'd draw it on a whiteboard: things as circles, the connections between them as lines. Those connections — the relationships — are stored as first-class data, so answering "what is this connected to" is a walk across the graph rather than a pile of joins reconstructed at query time.

Nodes, relationships, properties — the whole model

There are only three ingredients. A node is a thing: a person, an order, a document, a server. A relationship is a typed, directed connection between two nodes: (:Person)-[:PLACED]->(:Order). And properties are key–value pairs on either — a person's name, an order's total, the timestamp on a relationship.

That's it. You don't design tables and foreign keys up front; you add nodes and connect them. The schema can grow as your questions do, which is why graphs suit domains where you learn the important relationships over time rather than knowing them all on day one.

Why storing relationships as data changes the economics

In a relational database, a relationship between two rows is implied by a shared key and rebuilt every time you query — each hop is another JOIN, another index lookup, and the cost grows with the size of the tables you're joining. Ask a three-hop question and you're joining three tables; ask a variable-depth question ("how is A connected to B, however far apart they are") and SQL struggles to express it at all.

A graph database stores each relationship as a direct pointer from one node to its neighbour — often called index-free adjacency. Following a relationship is a constant-time step regardless of how big the overall graph is, so the third hop costs about the same as the first. Connected questions that degrade in a relational schema stay fast in a graph.

You write the pattern, not the plumbing

Graph databases are queried with a pattern-matching language. CognoDB speaks Cypher, where the query looks like the thing you're asking for — you draw the shape and the engine finds every match. Compare a two-hop "friends of friends who I don't already follow" in Cypher below to the equivalent triple self-join in SQL.

Friends-of-friends the current user doesn't already followcypher
MATCH (me:Person {id: $id})-[:FOLLOWS]->(friend)-[:FOLLOWS]->(fof)
WHERE NOT (me)-[:FOLLOWS]->(fof) AND fof <> me
RETURN fof.name, count(*) AS mutuals
ORDER BY mutuals DESC
LIMIT 10

When a graph is the right shape

A graph earns its place when the relationships are the point: multi-hop questions (recommendations, dependency chains, fraud rings), variable-depth traversals (ownership, lineage, reachability), and connected data that spans systems (knowledge graphs, identity resolution). If the interesting query is "what connects to what, and how," you're describing a graph.

It's the wrong tool for some jobs too — high-volume simple writes, full-table analytics, pure streaming. Being honest about that is its own page: see when not to use a graph database.

CognoDB is a managed graph database

CognoDB Cloud runs graph instances you provision instead of operate. It speaks Bolt 5.0–5.4 and understands Cypher, so the official Neo4j drivers for Python, JavaScript, Go, Java and .NET connect unchanged — migration is usually a one-line URI swap. Instances accept their first connection about 7 ms after starting, idle at roughly 15 MB, and bill by the second, so spinning one up to try a model is cheap enough to be an afterthought.

Questions

Common questions.

How is a graph database different from a relational database?

A relational database stores rows in tables and reconstructs relationships at query time with joins. A graph database stores relationships directly as data, so traversing them is a constant-time step per hop rather than a join whose cost grows with table size. Graphs win on connected, multi-hop questions; relational databases win on high-volume tabular workloads.

Is a graph database a type of NoSQL database?

It's usually grouped under NoSQL, but the label undersells it. CognoDB is fully ACID-transactional and queried with Cypher, a declarative language — closer in rigour to SQL than to a key-value store, just organised around relationships instead of tables.

Do I need to learn a new query language?

You'll write Cypher, which is designed to be readable — the query looks like the pattern you're matching. If you already use a Neo4j driver, you already speak it, and CognoDB accepts the same Cypher over the same Bolt protocol.

Are graph databases ACID?

CognoDB is. Writes are transactional, so a MERGE that creates a node and its relationships either fully commits or doesn't — the same guarantee you'd expect from a relational database, applied to graph data.

How large can a graph get?

CognoDB instances scale from 256 MB to 512 GB of memory with storage up to 4 TiB, resized without changing the connection URI. Many teams also run several smaller graphs — one per tenant, market or agent — rather than one giant one, because instances are cheap to provision.

Start now

~98.7%

token efficiency at 2,000 entities — see the footnotes above

Try the ideas on a real graph.

A free instance takes about a minute and no card. Every Cypher snippet on this page runs against it unchanged.

First-graph path

Live
  1. Create a free instance

    No card. Ready in about a minute.

  2. Connect your driver

    bolt+ssc:// URI into the driver you already use.

  3. Write two MERGEs

    That's the entire shape of agent memory.

  4. Point an agent at it

    One MCP config block. No integration code.