Knowledge Graph vs Relational Database

The "we need a knowledge graph" decision often defaults to "let's deploy Neo4j" without examining whether the data and queries actually warrant a graph database. Most knowledge-graph use cases work fine in Postgres with the right schema. Some genuinely don't.

This page is the decision criteria, the trade-offs, and the hybrid pattern that most mature systems converge on.

What a knowledge graph actually is

A KG stores entities (nodes) and typed relationships (edges) between them, with the relationships being first-class queryable.

(Anthropic) -[:founded_in]-> (San Francisco)
(Dario Amodei) -[:ceo_of]-> (Anthropic)
(Anthropic) -[:produces]-> (Claude)
(Anthropic) -[:competitor_of]-> (OpenAI)

Queries traverse: "what companies does Dario lead?" "what does Anthropic compete with?" "what are the products of companies founded in SF that compete with OpenAI?"

The shape that benefits: queries that follow many edges, where the joining structure isn't fixed, where you want to ask graph-shaped questions.

When a relational database is enough

You probably don't need a KG when:

Most CRUD systems, e-commerce, SaaS dashboards — these work in Postgres without a KG. A graph database adds operational complexity without providing usable benefit.

When a KG fits

You probably benefit from a KG when:

These are the hard sells. Identifying them requires understanding both your data and your queries.

The graph-on-relational pattern

Most KGs in 2026 don't use a graph database. They use Postgres with a graph schema:

CREATE TABLE nodes (
    id BIGSERIAL PRIMARY KEY,
    type TEXT NOT NULL,
    name TEXT NOT NULL,
    properties JSONB,
    UNIQUE (type, name)
);

CREATE TABLE edges (
    id BIGSERIAL PRIMARY KEY,
    source_id BIGINT NOT NULL REFERENCES nodes(id),
    target_id BIGINT NOT NULL REFERENCES nodes(id),
    relation TEXT NOT NULL,
    properties JSONB,
    confidence REAL,
    source TEXT
);

CREATE INDEX ON edges (source_id, relation);
CREATE INDEX ON edges (target_id, relation);

For 1-3 hop queries, this is fast. Recursive CTEs handle deeper traversals. The whole stack is Postgres; you have transactions, joins with non-graph tables, and the operational simplicity of one database.

This is what most production "knowledge graphs" actually are. Calling it a KG and serving it from Postgres is fine.

When you need an actual graph database

For specific cases:

For these, Neo4j, JanusGraph, TigerGraph, or AgensGraph make sense.

For most other cases, Postgres + graph schema wins on operational simplicity.

Triple stores (RDF)

A different KG flavour: triples (subject-predicate-object) with formal semantics (RDF, OWL, SPARQL). Stronger reasoning capabilities; useful for ontology-heavy domains (life sciences, library science, semantic web).

Less common in industry; most "knowledge graph" projects in 2026 use property graphs (Neo4j-style) or relational implementations.

Hybrid: Postgres with graph + relational + vector

The pattern most mature production knowledge bases land on:

Postgres with extensions:
  - Relational tables for structured data (users, accounts, orders).
  - nodes / edges tables for the graph layer.
  - pgvector for embeddings (semantic search).
  - JSONB for flexible properties.

Single substrate; transactional consistency; one ops story.

Queries cross layers:

-- Find users related to "AI" by topic, with their recent orders
SELECT u.name, COUNT(o.id) AS orders
FROM users u
JOIN edges e ON e.source_id = u.kg_node_id
JOIN nodes n ON n.id = e.target_id
LEFT JOIN orders o ON o.user_id = u.id
WHERE n.name = 'AI' AND e.relation = 'interested_in'
  AND o.created_at > NOW() - INTERVAL '30 days'
GROUP BY u.id, u.name;

This is the wiki you're looking at. The Wikantik knowledge graph is built on Postgres + pgvector + a graph schema. It works.

What KGs add to RAG

For retrieval-augmented generation:

Pure vector RAG doesn't do these well. KG-augmented RAG ("GraphRAG") fills the gap. Microsoft's GraphRAG project popularised the approach; many production systems now combine KG and vector retrieval.

See KnowledgeGraphCompletion for the construction side; RagImplementationPatterns for retrieval.

Practical decision criteria

For a new project considering a KG:

  1. Sketch the queries. What questions will you ask?
  2. For each query, write the SQL (assuming relational + JSONB). Is it ugly?
  3. For each query, write the Cypher (assuming graph DB). Is it materially better?
  4. If queries are simple in SQL, use Postgres. Add graph schema if you need some graph-shaped questions.
  5. If queries are genuinely graph-shaped and deep, evaluate Neo4j vs Postgres-graph-on-Postgres on your data scale.

Most projects stop at step 4. The minority needing step 5's graph DB are the genuinely graph-heavy use cases.

Failure modes

A pragmatic recommendation

For most teams in 2026:

This is conservative advice; deviate when you have a specific reason.

Further reading