Graph Database
A store whose first-class citizens are nodes and the relationships between them, making multi-hop traversal cheap.
The distinguishing property is index-free adjacency: a node holds direct pointers to its neighbours, so traversing a relationship is a pointer hop rather than an index lookup and a join. Traversal cost is proportional to the part of the graph you touch, not to the size of the dataset.
This matters for queries that are painful in SQL: "people connected to this person within three degrees", "every component that transitively depends on this library", "paths between these two accounts", "products bought by people who bought this". Each additional hop in a relational model is another self-join, and the cost grows sharply.
Where it is the wrong choice: aggregate reporting over the whole dataset, high-volume simple lookups, and anything where the relationships are shallow and fixed — a foreign key is a perfectly good relationship for one hop.
The honest position for most systems: the graph questions are a minority of the workload, so a graph database usually appears alongside a primary store rather than replacing it, which is polyglot persistence and carries its cost.