A graph database is a non-relational data model in which information is stored as nodes (the entities) and relationships (the connections between them), rather than as rows in tables. The Neo4j documentation describes this directly: data is held as “nodes, relationships, and properties instead of in tables or documents,” with each node tagged by labels and each relationship given a name and a direction. Crucially, both nodes and relationships can carry their own key-value properties.
The defining feature is that connections are stored as first-class objects in the database, not reconstructed at query time. In a relational database, a question like “who is connected to whom” requires joining tables on matching keys, and the cost of those joins grows as the chains of connections get longer. A graph database instead keeps direct pointers between connected records, so traversing from one node to its neighbors and onward is a cheap, local operation. This is why graph models excel at queries such as shortest path, friend-of-a-friend, and tracing relationship chains.
Because the model centers on relationships, query languages for graphs make connections explicit. Neo4j’s Cypher, for example, uses an ASCII-art pattern syntax where nodes are written in parentheses and relationships as arrows between them, treating a relationship as a thing you match directly rather than as an implied foreign key. The result is queries that read much like the relationship-shaped questions they answer.
Graph databases are one branch of the broader NoSQL family, alongside key-value, document, and wide-column stores. They tend to be the right tool when the structure of the connections is itself the data that matters, as in social networks, recommendation systems, knowledge graphs, and fraud or network analysis.