Knowledge Graphs, Vector Databases & RAG

Three terms that get used interchangeably - and shouldn't be. A knowledge graph, a vector database, and a RAG pipeline solve three different problems, and the fastest way to keep them straight is to poke at each one.

Every demo on this page runs entirely in your browser: no backend, no API keys, no model downloads. The vectors are toy-sized on purpose, so you can see the mechanics instead of taking them on faith. The same patterns run for real across my projects - the interactive graph on the homepage is a knowledge graph, and the fleet's search runs on Workers AI embeddings in Cloudflare Vectorize.

01 · Knowledge Graph

Entities and typed relationships

A knowledge graph stores entities (nodes) and the typed relationships between them (edges). The question it answers is "how is X connected to Y?" You get answers by walking edges, and every hop is explainable - the graph can always show its work.

Here is the real one - every shipped project and every shared package, drawn from the same data that powers the homepage graph. Click any node to see the facts (triples: subject, predicate, object) it participates in:

Click a node to list its triples.

The payoff is multi-hop reasoning. "Which shared package handles sign-in for Lost Pet Radar?" is two hops: from N along built, then along uses to LatentEdge Auth.

No graph database required At small scale a knowledge graph is a shape, not a product. This one is a JavaScript array of triples; the one on my homepage is the same idea; and in my fleet dashboard the graph is computed live from relational rows in D1 - foreign keys become edges. Dedicated graph databases earn their keep when you need to traverse millions of edges, not dozens.

02 · Vector Database

Meaning as geometry

A vector database stores meaning instead of relationships. Text is converted into a list of numbers (an embedding) - a point in high-dimensional space where nearby points carry similar meaning. The question it answers is "what is most like this?" - no keywords required.

Below is a corpus of twelve one-line documents about my projects, each already converted to a vector. Plotted by their two principal components - the two directions that capture the most variance across the corpus - documents about similar things land near each other without ever being told a category:

Click a dot to preview the document behind it.

Your query and every document become vectors, and results are ranked by cosine similarity - the angle between your query's vector and each document's. Run a search and watch a new point drop into the same space, closest to whatever it means: try "money stuff" or "how do people log in":

The toy vs. the real thing To stay dependency-free, this demo "embeds" text by counting words and folding synonyms through a small hand-written table - that's why money finds Stripe. Production systems replace the synonym table with a learned embedding model (my fleet uses bge-base-en-v1.5 on Workers AI: text in, 768 numbers out) where those associations are learned from data instead of listed by hand. Everything downstream - cosine similarity, k-nearest-neighbor search, even the 2D plot above (real principal component analysis, just over twelve dimensions instead of 768) - is exactly what you just ran.

Graph vs. vectors - when to use which

They're complementary, not competitors. The graph is precise about relationships; vectors are fuzzy about meaning. Mature systems use both - and a RAG pipeline is usually the reason you need them.

	Knowledge graph	Vector database
Data model	Entities + typed edges	Embeddings + metadata
Question it answers	"How is X connected to Y?"	"What is most similar to this?"
Query style	Traversal and pattern matching	k-nearest-neighbor similarity
Strong at	Precision, provenance, multi-hop reasoning	Fuzzy recall, natural-language queries
Weak at	"Things vaguely like this"	Explaining why two results relate
On this page	The clickable graph in 01	The search in 02
Role in RAG	Structured facts an LLM can walk	Passages an LLM reads as context

03 · RAG

Retrieval-augmented generation

RAG is how you make an LLM answer from your data instead of its training set: retrieve what's relevant, augment the prompt with it, then generate - with citations required and refusal instructed when the context doesn't cover the question. Grounding beats guessing.

Ask a question and watch the pipeline run. Stages 1-3 execute for real against the corpus from section 02; stage 4 is where a model would take over.

1 Embedquestion → vector

2 Retrievek nearest neighbors, k = 3

3 Augmentmatches → grounded prompt

4 GenerateLLM → cited answer

The production version My fleet dashboard runs this same loop end to end: documentation is chunked into overlapping ~1,200-character sections, embedded with Workers AI, and stored in Cloudflare Vectorize; questions are embedded the same way, matched by cosine similarity, hydrated from D1 (the vector store finds things - the relational store stays the source of truth), and answered by an LLM that must cite its sources and refuse when the context comes up empty.

question → embed → kNN → hydrate from D1
→ grounded prompt → LLM → cited answer   // one Worker endpoint

Wrap-up

Reach for a knowledge graph when the relationships are the data and answers must be explainable. Reach for a vector database when people will ask in their own words and you need fuzzy recall over lots of text. Reach for RAG when an LLM needs to answer from your data - and you'll usually find it wants both of the above: vectors for passages, the graph for facts.

The homepage graph is the first pattern live in ~100 lines of vanilla JavaScript. The other two run in production across the fleet on Workers AI, Vectorize, and D1.