Neo4j — Native Graph for Connected Data

Neo4j's core insight: make the relationship a real object with its own properties, not just a foreign-key number. Follow that pointer directly — no JOIN, no table scan — and multi-hop queries that would crush SQL become millisecond operations.

You do not need to know anything about graph databases to follow this story. Just follow the dots — literally.

The situation: a fraud ring hiding in plain sight

You are building the fraud-detection system for a fintech startup. A new user signs up. The account looks clean — real name, real email, real phone. Your rule-based system approves them. They apply for a $5,000 loan. The money disappears overnight.

What actually happened? Let's trace the connections:

• That user registered from an IP address. The same IP was used to sign up 5 other accounts in the past month.
• Two of those 5 accounts share a phone number with 12 other accounts.
• Eight of those 12 accounts share a device fingerprint with accounts that were already flagged as fraudulent.

The fraudulent user was three hops away from known bad actors. Your rules only looked one hop. The ring was invisible.

Why SQL can't catch this easily

To find that 3-hop fraud ring in a relational database, you write something like this:

-- 3-hop fraud ring detection in SQL (simplified)
SELECT DISTINCT u3.id
FROM users u1
JOIN ip_logins l1 ON u1.id = l1.user_id
JOIN ip_logins l2 ON l1.ip = l2.ip          -- hop 1: same IP
JOIN users u2 ON l2.user_id = u2.id
JOIN phone_links p1 ON u2.id = p1.user_id
JOIN phone_links p2 ON p1.phone = p2.phone  -- hop 2: shared phone
JOIN users u3 ON p2.user_id = u3.id
WHERE u3.is_flagged = true;

That is 6 JOINs for 3 hops. Each JOIN scans a table. With 50 million users, each of those table scans can hit millions of rows. Query time: potentially 10–30 seconds — if it finishes at all. Add a fourth hop and you might be waiting minutes. The query planner has no idea which rows are connected; it just scans and matches.

The same query in Neo4j Cypher

MATCH (suspect:User)-[:USES_IP|SHARES_PHONE*1..3]->(flagged:User {isFlagged: true})
WHERE suspect.id = $newUserId
RETURN flagged.id, length(path) AS hops

Neo4j walks the actual relationship pointers starting from the new user's node. It never touches users who aren't connected. With 50 million users and an average of 5 connections each, a 3-hop traversal visits roughly 5³ = 125 reachable candidates — not millions. Query time: roughly 50 milliseconds. Add more hops and it stays fast, because it's still following pointers, not scanning tables.

Here is the mental shift that makes everything else click. In a relational database, the connection between two pieces of data is not a real object — it is a number (a foreign key) that you use to look something up. In a graph database, the connection is a real thing, just as real as the data it connects. It has a type, a direction, and its own properties.

Foreign keys vs. first-class relationships

Say you want to store the fact that Alice worked at Acme Corp as an engineer from 2020 onwards. In SQL, you need a third table — an "employments" junction table — with columns for user_id, company_id, role, and start_date. The relationship is a row in a table you had to invent. In Neo4j, the relationship is the object: (Alice)-[:WORKED_AT {role: "engineer", since: 2020}]->(Acme). No junction table. No extra query. The context travels with the edge.

Four design heuristics to live by

Before writing a single Cypher query, you need six vocabulary words. Each one is simple — the table below makes them concrete. There are no hidden complexities here; Neo4j deliberately kept the model small so the learning curve stays gentle.

The "property graph" is not just a marketing name — it is a precise data model with specific rules. Understanding what those rules are (and what they are not) will help you design schemas that Neo4j handles efficiently and avoid patterns that feel unnatural in a graph.

The four rules of the property graph model

1. Nodes have zero or more labels, zero or more properties. A label is a string category tag. A property is a typed key-value pair (string, integer, float, boolean, date, or list of those).
2. Relationships have exactly one type (a string, uppercase by convention), exactly one direction (from source to target), and zero or more properties. Every relationship has a start node and an end node — they cannot be dangling.
3. Multiple labels per node are allowed. A node can simultaneously be :Person, :Employee, and :Author. This is useful for querying the same node from multiple angles.
4. No fixed schema by default. Two nodes with the same label can have completely different properties. You can add optional CONSTRAINTS to enforce uniqueness or property existence when you need consistency.

How the property graph compares to alternatives

The property graph is not the only graph data model. Two others appear in the wild enough to be worth knowing:

• RDF (Resource Description Framework) — the W3C standard for the "semantic web." RDF stores data as triples: subject, predicate, object (e.g., <Alice> worksAt <Acme>). It is deeply standardised and integrates well with ontologies and linked open data. The trade-off: RDF is verbose, the tooling is academic-feeling, and it is harder to map to everyday application models. Most app developers find the property graph easier to think in.
• Hypergraph — a mathematical model where a single "hyperedge" can connect any number of nodes (not just two). This is rarely used in mainstream databases but appears in some research and data science contexts. The property graph's constraint of exactly-two-node relationships is a practical simplification that makes storage and traversal tractable.

// Create two Person nodes and connect them with a KNOWS relationship
CREATE (alice:Person {name: "Alice", age: 31, city: "London"})
CREATE (bob:Person {name: "Bob", age: 28, city: "Berlin"})

// Now connect them — the relationship carries its own properties
MERGE (alice)-[:KNOWS {since: 2019, strength: "close"}]->(bob)

// Verify: find the relationship you just created
MATCH (a:Person {name: "Alice"})-[r:KNOWS]->(b:Person)
RETURN a.name, r.since, r.strength, b.name
// Result: "Alice" | 2019 | "close" | "Bob"

// A node can have multiple labels at once — this person is also an employee
CREATE (alice:Person:Employee {
  name: "Alice",
  employeeId: "E-1042",
  department: "Engineering"
})

// You can query by either label independently
MATCH (p:Person) RETURN p.name           // finds Alice
MATCH (e:Employee) RETURN e.employeeId  // also finds Alice

// Or query the intersection — nodes that are BOTH
MATCH (pe:Person:Employee)
RETURN pe.name, pe.department
// Result: "Alice" | "Engineering"

// Relationship properties carry context that doesn't belong on either node
MATCH (alice:Person {name: "Alice"})
MATCH (acme:Company {name: "Acme Corp"})

CREATE (alice)-[:WORKED_AT {
  role: "Senior Engineer",
  since: date("2020-03-01"),
  until: date("2023-11-30"),
  remote: true
}]->(acme)

// Retrieve and filter by relationship property
MATCH (p:Person)-[job:WORKED_AT]->(c:Company)
WHERE job.role STARTS WITH "Senior"
  AND job.remote = true
RETURN p.name, c.name, job.role, job.since
// Works like any property query — just on the edge instead of a node

Most query languages describe operations: SELECT this column FROM this table WHERE this condition. Cypher describes shapes: "find a graph that looks like this." You draw the pattern you want using ASCII art notation, and Neo4j finds every subgraph in the database that matches your drawing. This is a fundamentally different mental model — and most developers find it more intuitive for relationship queries than SQL joins.

The visual nature of Cypher vs. SQL verbosity

The five Cypher patterns every engineer needs

Cypher has just five fundamental patterns. Memorise these five shapes and you can read and write 90% of real-world Cypher queries.

// Find all friends-of-friends of Alice who are NOT already her direct friends
// This is a classic social-graph query — 3 lines in Cypher, 9+ lines in SQL

MATCH (alice:Person {name: "Alice"})-[:KNOWS]->(friend)-[:KNOWS]->(fof:Person)
WHERE NOT (alice)-[:KNOWS]->(fof)   // exclude people already in her 1-hop network
  AND fof <> alice                  // exclude herself
RETURN fof.name, count(friend) AS mutualFriends
ORDER BY mutualFriends DESC
LIMIT 10

// count(friend) = number of mutual friends — useful for ranking suggestions
// "Return the top 10 strangers Alice has the most mutual friends with"
// This is exactly how LinkedIn's "People you may know" works conceptually

// Collaborative filtering — "users who bought what Alice bought also bought what?"
// This is the basic engine behind Amazon's "Customers also bought" feature

MATCH (alice:User {id: $userId})-[:PURCHASED]->(product:Product)
      <-[:PURCHASED]-(similar:User)     // users who share at least one purchase
      -[:PURCHASED]->(rec:Product)      // products those users also bought
WHERE NOT (alice)-[:PURCHASED]->(rec)   // Alice hasn't bought the recommendation yet
RETURN rec.name,
       rec.category,
       count(similar) AS sharedBuyers,  // how many similar users bought this
       avg(rec.rating) AS avgRating
ORDER BY sharedBuyers DESC, avgRating DESC
LIMIT 20

// The graph traversal here is 3 hops:
// Alice → her purchases → users who also bought those → their other purchases
// In SQL this requires 3 self-joins across the purchases table — one query, but messy

// Shortest path between two people — "how is Alice connected to Charlie?"
// Neo4j has a built-in shortestPath() function that uses BFS internally

MATCH path = shortestPath(
  (alice:Person {name: "Alice"})-[:KNOWS*]-(charlie:Person {name: "Charlie"})
)
RETURN path,
       length(path) AS degrees,        // number of hops (the "degrees of separation")
       [n IN nodes(path) | n.name]     // list every person on the path
// Result example: ["Alice", "Bob", "Diana", "Charlie"] | degrees: 3

// allShortestPaths() returns ALL shortest paths if you want alternatives:
MATCH paths = allShortestPaths(
  (alice:Person {name: "Alice"})-[:KNOWS*]-(charlie:Person {name: "Charlie"})
)
RETURN [n IN nodes(paths) | n.name] AS path, length(paths) AS hops
ORDER BY hops

Here is the most important performance fact in all of graph databases: in Neo4j, jumping from one node to a related node costs the same tiny fixed amount of work, no matter how big your data gets. In a relational database, the same jump gets slightly slower as your tables grow — every JOIN walks a small tree to find the matching row. Engineers shorthand this as O(1) for the graph (constant cost per hop) versus O(log N) for the relational lookup (cost grows with the size of the data, slowly but steadily). That difference sounds small until you need to do it five times in a row.

Imagine you want to find "friends of friends of friends" — a classic social graph query. In SQL you JOIN three tables together, and each JOIN forces the database to look up keys in a B-tree index. With one million rows, each lookup is about 20 steps deep into a tree. Five JOINs = 5 × 20 = 100 index operations, and that cost grows with your data. In Neo4j, every node holds a direct pointer to its relationships — like a contact card with arrows already drawn to each friend. Following five hops is five pointer reads, not five index searches. It does not matter if you have one million nodes or one billion: the cost per hop is the same. Engineers call this trick index-free adjacency — the connections live inside the data itself, so no index lookup is needed to follow them.

The name "index-free adjacency" captures the idea precisely: the adjacency (the connections) is stored in the data structure itself, not in a separate index. Every node record physically contains a pointer to its first relationship. That relationship record contains a pointer to the next relationship for the same node. You traverse a chain, not an index tree.

This is why graph databases shine for deep traversals — queries with more than 3 or 4 hops. For a flat query like "find all users with email = 'x@example.com'", SQL with a proper index is perfectly competitive. But ask "find all people within 4 degrees of Alice who bought a product in Alice's category" and Neo4j wins by orders of magnitude.

Most people think of databases as tables on disk. Neo4j thinks of disk as a collection of fixed-size records, each one representing either a node, a relationship, or a property. The format is not rows and columns — it is records and pointers. Understanding this layout explains why the performance characteristics described in the previous section are physically real, not just theoretical.

Neo4j maintains four separate stores on disk. Think of each store as a flat file where records sit at predictable offsets. Because each record is a fixed size, finding record number N is just a multiplication: offset = N × record_size. No B-tree needed to find a record by ID — just a seek.

Let's walk through each store and why it is designed the way it is.

In Section 5, you learned the basics of Cypher: how to MATCH a pattern, SET properties, and RETURN results. But real-world Neo4j applications need much more. Recommendation engines need to find people "within three degrees". Logistics systems need the shortest route between two cities. Fraud analysts need optional context that may or may not exist. This section takes Cypher from hobbyist to professional.

Think of these patterns as the verbs and sentence structures of the Cypher language. The basic MATCH + RETURN is like knowing nouns and verbs in English. The patterns here are what let you write full paragraphs — complex ideas expressed clearly and precisely.

MATCH (alice:Person {name:"Alice"})-[:KNOWS*1..3]->(person)
RETURN DISTINCT person.name

MATCH (a:City {name:"London"}), (b:City {name:"Tokyo"})
MATCH p = shortestPath((a)-[:ROUTE*..15]->(b))
RETURN p, length(p) AS hops

MATCH (u:User)
OPTIONAL MATCH (u)-[:HAS_SUBSCRIPTION]->(s:Subscription)
RETURN u.name, s.expiresAt

MATCH (p:Product)<-[:PURCHASED]-(u:User)
RETURN p.name, count(u) AS buyers, collect(u.name) AS buyerNames
ORDER BY buyers DESC LIMIT 10

MATCH (u:User)-[:PURCHASED]->(p:Product)
WITH u, count(p) AS purchases
WHERE purchases > 5
MATCH (u)-[:LIVES_IN]->(c:City)
RETURN u.name, purchases, c.name

MATCH (u:User)
RETURN u.name,
  CASE
    WHEN u.age < 18 THEN "minor"
    WHEN u.age < 65 THEN "adult"
    ELSE "senior"
  END AS ageGroup

// Recommendation: products bought by Alice's extended network
MATCH (alice:User {name:"Alice"})-[:KNOWS*1..2]->(friend:User)
MATCH (friend)-[:PURCHASED]->(product:Product)
WHERE NOT (alice)-[:PURCHASED]->(product)
RETURN product.name, count(DISTINCT friend) AS socialProof
ORDER BY socialProof DESC
LIMIT 10

// Shortest flight-hop path between two cities
MATCH (origin:City {name:"London"}), (dest:City {name:"Tokyo"})
MATCH p = shortestPath((origin)-[:FLIGHT*..15]->(dest))
RETURN
  [city IN nodes(p) | city.name] AS route,
  length(p) AS stops,
  reduce(total=0, r IN relationships(p) | total + r.distanceKm) AS totalKm

// Most popular product categories by purchase volume
MATCH (u:User)-[:PURCHASED]->(p:Product)-[:IN_CATEGORY]->(c:Category)
WITH c, count(DISTINCT p) AS uniqueProducts, count(u) AS totalPurchases
RETURN c.name        AS category,
       uniqueProducts,
       totalPurchases,
       round(toFloat(totalPurchases) / uniqueProducts, 2) AS avgPurchasesPerProduct
ORDER BY totalPurchases DESC
LIMIT 20

Here is a common misconception: "Neo4j has index-free adjacency, so it doesn't need indexes." That's wrong in a very specific way. Neo4j does NOT need indexes to traverse a graph — that's the pointer-chain magic from Section 7. But to start a traversal, you need to find your first node. If you want to match (p:Person {email: 'alice@example.com'}), without an index Neo4j would have to scan every single Person node to find Alice. That would be painfully slow.

Think of it like a subway map. The map itself (the graph structure) tells you every route between any two stations — that's index-free adjacency. But to use the map, you first have to find your starting station on the board. An index is the "station finder" — the lookup that gets you to node #12,345 so the graph traversal can begin.

// Create range index (default in Neo4j 5; was B-tree pre-5.0)
CREATE INDEX person_email_idx FOR (p:Person) ON (p.email);

// Verify the query planner uses it
EXPLAIN
MATCH (p:Person {email: "alice@example.com"})
RETURN p;
// Output should show "NodeIndexSeek" (not "NodeByLabelScan")

// Optional: give the index a name for easier dropping later
CREATE INDEX person_email_idx IF NOT EXISTS
FOR (p:Person) ON (p.email);

// Create unique constraint (also creates the backing index)
CREATE CONSTRAINT user_email_unique
FOR (u:User) REQUIRE u.email IS UNIQUE;

// Now this throws an error if email already exists:
CREATE (u:User {email: "alice@example.com", name: "Alice"});

// Use MERGE to do "create if not exists" safely:
MERGE (u:User {email: "alice@example.com"})
ON CREATE SET u.name = "Alice", u.createdAt = datetime()
ON MATCH  SET u.lastSeen = datetime()
RETURN u;

// Create vector index (768-dim embeddings, cosine similarity)
CREATE VECTOR INDEX product_embedding_idx
FOR (p:Product) ON (p.embedding)
OPTIONS {
  indexConfig: {
    `vector.dimensions`: 768,
    `vector.similarity_function`: "cosine"
  }
};

// Query: find 10 products most similar to a given embedding vector
CALL db.index.vector.queryNodes(
  "product_embedding_idx",
  10,                       -- top K results
  $queryEmbedding           -- float[] parameter from application
) YIELD node AS product, score
RETURN product.name, product.price, score
ORDER BY score DESC;

When a bank moves money from your account to someone else's, two things must happen together — money leaves your account AND money arrives in theirs. If only one half happens, money has effectively vanished or appeared. The four guarantees that prevent that kind of broken-in-the-middle state are bundled under the acronym ACID (Atomicity, Consistency, Isolation, Durability). Most NoSQL databases sacrifice some or all of these in exchange for speed or horizontal scale. Neo4j makes the opposite bet: full ACID transactions, including in clusters. This is a big deal and a deliberate choice. Graph data — particularly fraud graphs, compliance audit trails, and identity systems — is often mission-critical. You cannot have a transaction that partially transfers money or half-links an identity node.

ACID stands for four guarantees. Think of them as the four rules a trustworthy bank should follow: all operations in one action succeed together, the account balances always add up correctly, your in-progress work doesn't corrupt other people's in-progress work, and once the bank says "done" the data is saved even if the power goes out.

When you run multiple Neo4j servers together for fault tolerance, durability goes a step further. Before saying "yes, your write is saved," the leading server first asks the others "did you record this too?" — and waits for a majority to say yes. Neo4j calls this multi-server setup a Causal Cluster, and the rule that "a majority must agree before we count it as saved" is part of an algorithm called Raft. The majority itself is called a quorum. This means a single server crash immediately after your commit cannot lose your data — the other core members already have it.

// This single statement is automatically wrapped in a transaction
MERGE (u:User {email: $email})
ON CREATE SET
  u.name      = $name,
  u.createdAt = datetime()
RETURN u.email, u.createdAt

# Python driver: explicit transaction with retry
def transfer_funds(tx, from_id, to_id, amount):
    tx.run("""
        MATCH (src:Account {id: $from_id})
        WHERE src.balance >= $amount
        SET src.balance = src.balance - $amount
    """, from_id=from_id, amount=amount)

    tx.run("""
        MATCH (dst:Account {id: $to_id})
        SET dst.balance = dst.balance + $amount
    """, to_id=to_id, amount=amount)

    tx.run("""
        CREATE (:Transfer {
          fromId: $from_id, toId: $to_id,
          amount: $amount, ts: datetime()
        })
    """, from_id=from_id, to_id=to_id, amount=amount)
    # All three run in ONE transaction — all-or-nothing

with driver.session() as session:
    session.write_transaction(transfer_funds, "acc-001", "acc-002", 500)

# Write to leader; get bookmark
with driver.session(database="neo4j") as session:
    session.write_transaction(
        lambda tx: tx.run("CREATE (u:User {name: $name})", name="Alice")
    )
    bookmark = session.last_bookmarks()  # capture the causal marker

# Read with bookmark → guaranteed to see Alice's node
with driver.session(
    database="neo4j",
    bookmarks=bookmark          # wait until replica catches up to this point
) as session:
    result = session.run("MATCH (u:User {name:'Alice'}) RETURN u")
    print(result.single())

A single Neo4j server will get you a long way — the in-memory caching and pointer-based traversal are highly efficient. But production systems need fault tolerance, and read-heavy workloads benefit from scale-out. Neo4j Enterprise offers two clustering models. The first, Causal Cluster, is mature and battle-tested. The second, Autonomous Cluster (Neo4j 5.0+), targets planet-scale sharding. This section explains how each works and why graph sharding is uniquely difficult.

Let's break down each component and why it is designed the way it is.

A note on the harder problem: sharding a graph is fundamentally difficult. In a relational database, you can shard by user ID — row X goes to shard A, row Y goes to shard B. Relationships don't cross shards. In a graph database, a relationship between two nodes might need to cross shard boundaries, and every cross-shard hop requires a network round-trip, destroying the pointer-walk performance advantage. This is why Neo4j (and most graph databases) started as single-server or leader-follower architectures.

Graph databases shine hardest when the relationship is the data. In a social network, the interesting question is not "how old is Alice?" — it's "who does Alice know, who do those people know, and is there a fraud ring hiding in those connections?" That's a relationship question. And that's exactly what Neo4j was built to answer.

Below are six canonical places where teams reach for Neo4j — and a quick explanation of why graphs win in each case.

Neo4j ships with the Graph Data Science (GDS) library — a collection of roughly 65 graph algorithms you can run directly inside the database. The key insight: instead of exporting your graph to a separate analytics system, you run the algorithms where the data already lives. That cuts out the ETL pipeline entirely and keeps results fresh.

Most GDS algorithms don't run directly on your live database. Instead, they take a copy of just the nodes and relationships they need and load that copy into memory — so the heavy maths doesn't slow down ordinary queries. Neo4j calls this in-memory copy a projected graph. The pattern is always the same three steps: project just the slice you need, run the algorithm on the projection, then write results back into your real graph as node properties so Cypher queries can use them. Here are the five main algorithm families.

Scale note: GDS can run in-memory (full projected graph in RAM) or on-disk for very large graphs. With appropriate hardware, GDS can reportedly handle graphs with billions of nodes and relationships for centrality and community algorithms — though performance varies significantly by algorithm and data shape. Always benchmark with your actual data.

GDS in Practice — Three Algorithm Examples

// 1. Project the sub-graph into GDS memory
CALL gds.graph.project(
  'social-graph',          // name for this projection
  'Person',                // node label to include
  'FOLLOWS'                // relationship type to include
);

// 2. Run PageRank and write scores back to each node
CALL gds.pageRank.write(
  'social-graph',
  {
    maxIterations: 20,
    dampingFactor: 0.85,        // standard Google PageRank value
    writeProperty: 'pageRankScore'
  }
)
YIELD nodePropertiesWritten, ranIterations;

// 3. Query the top 10 influencers
MATCH (p:Person)
RETURN p.name AS influencer, p.pageRankScore AS score
ORDER BY score DESC
LIMIT 10;

// 4. Clean up the projection when done (free memory)
CALL gds.graph.drop('social-graph');

// Project graph with relationship weight
CALL gds.graph.project(
  'weighted-social',
  'Person',
  {
    INTERACTS: { properties: 'weight' }  // weight = interaction frequency
  }
);

// Run Louvain — write communityId to each node
CALL gds.louvain.write(
  'weighted-social',
  {
    writeProperty: 'communityId',
    relationshipWeightProperty: 'weight'
  }
)
YIELD communityCount, modularity;
// communityCount tells you how many clusters were found
// modularity (0–1) tells you how strong the community structure is

// Query: who is in community 42?
MATCH (p:Person { communityId: 42 })
RETURN p.name, p.communityId
ORDER BY p.name;

// Count community sizes
MATCH (p:Person)
RETURN p.communityId AS community, count(*) AS size
ORDER BY size DESC;

// Project: User nodes and PURCHASED relationships
CALL gds.graph.project(
  'purchase-graph',
  ['User', 'Product'],
  'PURCHASED'
);

// Run node similarity (Jaccard) and write top-5 similar users per user
CALL gds.nodeSimilarity.write(
  'purchase-graph',
  {
    writeRelationshipType: 'SIMILAR_TO',
    writeProperty: 'score',
    topK: 5                   // keep top 5 similar users per node
  }
)
YIELD nodesCompared, relationshipsWritten;

// Now recommend: products bought by similar users but not by Alice
MATCH (alice:User { name: 'Alice' })-[:SIMILAR_TO]->(similar:User),
      (similar)-[:PURCHASED]->(product:Product)
WHERE NOT (alice)-[:PURCHASED]->(product)
RETURN product.name AS recommendation,
       avg(similar.score) AS relevance
ORDER BY relevance DESC
LIMIT 10;

Neo4j performance comes down to three big ideas: keep the hot part of your graph in memory, index your entry points, and understand what your queries are actually doing. Most performance problems trace back to one of these being misconfigured.

Graph schema feels more flexible than SQL — you don't write CREATE TABLE first. But that flexibility is a trap if you design without discipline. A well-modeled graph is fast, readable, and easy to query. A poorly modeled one has super-nodes that kill performance and queries that are hard to write.

Here are five common modeling patterns, with the reasoning behind each.

Running Neo4j in production means thinking about six things: how do you back it up, how do you know it's healthy, how do you upgrade it without downtime, who can access what, how do you manage a cluster, and what tools do operators actually use day-to-day?

# Online backup (database stays running)
neo4j-admin database backup \
  --to-path=/backups/neo4j \
  --database=neo4j

# Offline dump (database must be stopped)
neo4j-admin database dump \
  --to-path=/backups/neo4j-dump.tar \
  --database=neo4j

# Restore from dump
neo4j-admin database load \
  --from-path=/backups/neo4j-dump.tar \
  --database=neo4j \
  --overwrite-destination=true

The graph database landscape has thinned significantly since 2020 — several early competitors were acquired or shut down. What's left is a short list of serious options, each with a distinct reason to exist. Neo4j remains the most widely adopted native graph database, but it's not always the right answer.

Neo4j ships with a surprisingly complete toolbox. Whether you are a developer writing code, an analyst clicking through data visually, or an ops engineer keeping the database healthy, there is a dedicated tool for you. Here is the rundown of the six tools you will reach for most, followed by working code samples for the three most common driver languages.

Driver Code Examples

# Connect to a local Neo4j instance
cypher-shell -u neo4j -p secret123

# Once inside the REPL — find friends-of-friends
neo4j@neo4j> MATCH (me:Person {name:"Alice"})-[:FRIEND_OF*2]->(fof)
             WHERE NOT (me)-[:FRIEND_OF]->(fof) AND me <> fof
             RETURN fof.name, fof.city
             LIMIT 10;

# Run non-interactively from a shell script
echo "MATCH (n:Person) RETURN count(n) AS total;" \
  | cypher-shell -u neo4j -p secret123 --format plain

from neo4j import GraphDatabase

# Create a driver — connection pool is managed automatically
driver = GraphDatabase.driver(
    "bolt://localhost:7687",
    auth=("neo4j", "secret123")
)

def find_friends_of_friends(tx, name: str) -> list[dict]:
    result = tx.run(
        """
        MATCH (me:Person {name: $name})-[:FRIEND_OF*2]->(fof)
        WHERE NOT (me)-[:FRIEND_OF]->(fof) AND me <> fof
        RETURN fof.name AS name, fof.city AS city
        LIMIT 10
        """,
        name=name,
    )
    return [{"name": r["name"], "city": r["city"]} for r in result]

# Sessions are lightweight wrappers; always use `with` so they close
with driver.session(database="neo4j") as session:
    suggestions = session.execute_read(find_friends_of_friends, "Alice")
    for s in suggestions:
        print(f"  {s['name']} ({s['city']})")

driver.close()

import neo4j from "neo4j-driver";

// A single driver instance per application — it manages a connection pool
const driver = neo4j.driver(
  "bolt://localhost:7687",
  neo4j.auth.basic("neo4j", "secret123")
);

async function findFriendsOfFriends(name) {
  const session = driver.session({ database: "neo4j" });
  try {
    const result = await session.run(
      `MATCH (me:Person {name: $name})-[:FRIEND_OF*2]->(fof)
       WHERE NOT (me)-[:FRIEND_OF]->(fof) AND me <> fof
       RETURN fof.name AS name, fof.city AS city
       LIMIT 10`,
      { name }
    );
    return result.records.map((r) => ({
      name: r.get("name"),
      city: r.get("city"),
    }));
  } finally {
    await session.close();  // always close — returns connection to pool
  }
}

const suggestions = await findFriendsOfFriends("Alice");
suggestions.forEach((s) => console.log(`${s.name} (${s.city})`));

await driver.close();

Graph databases carry a lot of baggage — myths that spread because most engineers learned databases through relational systems and map their existing mental model onto everything new. Each misconception below has a crisp factual correction and the reasoning chain behind it. Clear these up early and you will make far better decisions about when to reach for Neo4j.

The best way to learn what not to do is to study the failures others already paid for. Every one of these disasters happened in a real production system. The patterns are common enough that if you skip this section, you are likely to repeat at least one of them.

If there were one section to print out and stick above your monitor, this would be it. Every point below is a distillation of a real performance issue or architectural lesson. None of them require exotic tuning — they are standard practice for any Neo4j deployment beyond a toy project.

These are the questions that come up most often when engineers first encounter Neo4j — in interviews, in architecture reviews, and in onboarding sessions. Each answer is written for someone who already knows relational databases but is new to graph systems.

Neo4j makes most sense when you understand what it is contrasting with. Study these topics to build a complete mental map of the database landscape — so the next time you face a data architecture decision, you reach for the right tool rather than the most familiar one.