Knowledge Graphs, Vector Databases & RAG

These three terms get used like they mean the same thing but they do not. 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 in your browser. There is no backend, no API key, and nothing to download. The vectors are small on purpose so you can actually see how it works. 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 the edges, and every hop can be shown to the user.

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 useful part 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 just a shape. You do not need a product for it. This one is a JavaScript array of triples. The one on my homepage is the same idea. In my fleet dashboard the graph is computed live from relational rows in D1, where foreign keys become edges. You only need a real graph database once you are traversing millions of edges.

02 · Vector Database

How a vector database works

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?" You do not need matching keywords.

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 end up near each other, and nothing in the data told them what category they are in:

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 a new point gets added to the same plot, near the documents closest to it in meaning: 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 is the same either way. Cosine similarity, k-nearest-neighbor search, and the 2D plot above are all real. The plot is real principal component analysis, just over twelve dimensions instead of 768.

Graph vs. vectors - when to use which

You do not have to pick one. A graph is precise about relationships and a vector database is fuzzy about meaning. Most real systems end up using both, and RAG is usually the reason why.

	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. You retrieve what's relevant, augment the prompt with it, then generate. The prompt tells the model to cite its sources and to say it does not know when the context does not answer the question.

Ask a question below and the pipeline will 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. Documentation gets chunked into overlapping sections of about 1,200 characters, embedded with Workers AI, and stored in Cloudflare Vectorize. Questions get embedded the same way and matched by cosine similarity. The matches are pulled from D1, which stays the source of truth. The LLM has to cite its sources and has to refuse when the context does not cover the question.

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

Wrap-up

Use a knowledge graph when the relationships are the actual data and you need to explain the answer. Use a vector database when people will ask in their own words over a lot of text. Use RAG when you want an LLM to answer from your data. In practice RAG usually needs both of the others, vectors for the passages and the graph for the facts.

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