Graph databases store and query connected data as nodes and relationships rather than rows and tables, with Neo4j's native architecture enabling constant-time traversal across millions of hops. Cypher, Neo4j's declarative query language, uses ASCII-like patterns to intuitively express graph queries where relationships are stored as physical pointers instead of costly JOINs.
Neo4j is a database management system built from the ground up to store, query, and traverse connected data — data whose meaning is largely defined by the relationships between entities, not just the entities themselves. Where traditional relational databases organise information into rows and tables, Neo4j models data as a property graph: a network of nodes (entities) and relationships (connections), each of which can carry arbitrary key-value properties.
The word native is important here. Neo4j does not translate graph operations into SQL or map them onto a foreign storage engine. Its storage layer and query execution engine are purpose-built for graph traversal, which means following a chain of relationships — even across millions of hops — is a constant-time operation per hop rather than an exponentially expensive join.
Many real-world problems are inherently relational:
In a relational database, answering these questions requires multi-level JOIN operations whose cost grows with the depth of traversal. Neo4j resolves this by storing relationships as physical pointers between records, so a traversal follows a pointer rather than scanning an index.
Every piece of data in Neo4j lives within one unified structure:
Person, a Product, a Transaction).KNOWS, PURCHASED, TRANSFERRED_TO).name: "Alice", amount: 250.00).Person, Employee).Neo4j's declarative query language is called Cypher. Its central insight is that queries look like the graph patterns they describe. A pattern such as:
(alice:Person)-[:KNOWS]->(bob:Person)
reads almost like an ASCII-art diagram of two people connected by a KNOWS relationship. Full Cypher queries use MATCH to find patterns, WHERE to filter, and RETURN to project results — analogous to SELECT … FROM … WHERE in SQL, but operating on graph topology rather than table rows.
Neo4j supports range indexes, full-text indexes, and vector indexes on node and relationship properties. Uniqueness constraints and property existence constraints enforce data integrity, playing a role similar to UNIQUE and NOT NULL in SQL.
Neo4j is fully ACID-compliant. Every read and write participates in a transaction, ensuring that the graph remains consistent even under concurrent workloads or partial failures.
| Mode | Description |
|---|---|
| Neo4j AuraDB | Fully managed cloud service (AuraDB Free, Professional, Enterprise) |
| Neo4j Server | Self-hosted instance, configurable for single-node or clustered deployments |
| Causal Cluster | Multi-node setup with a leader-follower replication model for high availability |
| Neo4j Desktop | Developer workstation tool bundling the database, Browser, and Bloom |
High-level architecture of the Neo4j platform: storage and query layers sit at the top, with developer tools and deployment options below.
| Aspect | Relational DB | Neo4j |
|---|---|---|
| Data model | Tables and rows | Nodes and relationships |
| Schema | Fixed, upfront DDL | Flexible; evolve at runtime |
| Relationship storage | Foreign keys + JOIN | Physical pointers (native) |
| Query language | SQL | Cypher |
| Deep traversal cost | Exponential (JOINs) | Linear in path length |
| Recursive queries | WITH RECURSIVE (awkward) | Natural in Cypher |
A solid understanding of Neo4j builds from the ground up:
MATCH, CREATE, RETURN.UNWIND, CALL subqueries.Each of these topics is covered in dedicated documents within this knowledge base.