SELECT * FROM hot_takes WHERE topic = 'graph_dbs';

The Graph I Didn't Need

I built this visualization to show how concepts connect. It's pretty. It's interactive. Hover over the nodes. Watch the edges glow.

Then I deleted it from my homepage.

Initializing knowledge graph...

The confession

I spent hours on this component. Custom SVG rendering, hover states, edge highlighting, responsive sizing. It looks exactly like the Ideologos interface I was inspired by.

And then I realized: this is exactly what I argue against.

The Postgres way

Need relationships?

Foreign keys. You already have them.

Need semantic search?

pgvector. Same database.

Need flexible schema?

JSONB. Index it too.

Need graph traversal?

Recursive CTEs. SQL is fine.

The math

Graph database: Another system to deploy, monitor, backup, scale, debug, and pay for.

Postgres: You already have it. It already works.

80% of the “knowledge graph” use cases are just foreign keys with better marketing.

The exception

If you're doing real graph algorithms at scale—PageRank, community detection, pathfinding on billions of edges—yes, use a graph database.

But that's not what most “knowledge graphs” are. Most are just “I have entities with relationships” which is... a relational database.