Graph is a way of shaping data, not a product you must buy. Most workloads need the model and not the engine.
The word names two different things and the conflation costs projects real money. A graph is a data model: entities as nodes, relationships as first-class edges, questions answered by traversal. A graph database is an engine optimised for that model. Wanting the first does not oblige you to buy the second, and treating them as one decision turns a modelling choice into a procurement project.
The honest criterion is traversal depth and shape. Deep, variable-length paths — four hops and beyond, unknown in advance — genuinely need a graph engine; that is what it is built for. One to three hops with predictable patterns are served perfectly well by triples in a relational store with recursive SQL, on infrastructure you already run, back up and know how to operate. The second case covers a great deal more real work than the marketing suggests.
This matters because the graph model is the valuable part and the engine is the expensive part. Structuring your knowledge as entities and typed relationships is what makes reasoning possible, and you can do that in files, in markdown links, in a relational table, in DuckDB. What you gain from a dedicated engine is performance on a specific access pattern — and what you take on is another system with its own operations, its own sync problem, and its own drift between it and the source of truth.
The general form of the mistake is worth recognising because it recurs: mistaking a way of organising things for a thing you must purchase. Layers of storage are not an architecture. A connector is not a memory. A graph engine is not a knowledge graph. In each case the naming borrows authority from the model to sell the tool — and the model was the part that was doing the work.