Knowledge graphs attract mythology. Someone draws a constellation of nodes, says the word “semantics,” and the room forgets about late-arriving data and broken foreign keys.
I like graphs. I have spent a lot of time with them in production data platforms. They are a tool — excellent for some jobs, expensive for others.
What graphs are good at
- Relationship-heavy queries that become painful as multi-way joins
- Investigation workflows where an analyst needs neighborhood context
- Modeling provenance and lineage as first-class edges
- Entity resolution outputs that need to be explored, not only counted
If your access patterns are mostly “filter a wide table and aggregate,” a warehouse table may be the boring winner.
Entity resolution is not a logo
Resolving identities across sources is a pipeline problem: blocking, scoring, clustering, evaluation, and operability. The graph is often the serving and investigation layer for resolved entities and evidence — not a substitute for careful batch design.
See: Entity Resolution Lab (genericized patterns only).
Lineage is a product feature
When something looks wrong, the first question is not “which model?” — it is “what inputs and transforms produced this?” Treating lineage as a first-class graph (or graph-like structure) pays down trust debt.
Practical cautions
- Schema evolution will hurt; plan for it
- Unique constraints and idempotent writers matter more than demo queries
- “We put it in Neo4j” is not an architecture review
Closing
Use graphs when relationships are the product. Use tables when tables are enough. Measure both against the queries you actually run.
TODO: Add a public diagram of a generic entity/evidence model when available.