OKF vs RAG vs vector databases: what differs, and when to use each
Headlines like "Beyond RAG: OKF is replacing the vector database" are compelling, but they also blur the boundary between three things that live at different layers.
If you are not sure what OKF is yet, start with the first article in this series. Here I go straight at the question people actually get stuck on: how are these three different, and when do I use which?
Start here: Will Google OKF replace RAG and vector databases?Put the three back in their proper layers
A simple way to remember it: OKF answers "what should knowledge look like," RAG answers "how to fetch external knowledge and generate," and a vector database answers "how to store vectors and do semantic similarity search." Each handles a different layer of the problem.
| OKF | RAG | Vector database | |
|---|---|---|---|
| What it is | A representation / interchange format | A retrieval workflow | A retrieval infrastructure |
| Which layer | How knowledge is authored, linked, versioned | How to fetch external knowledge before generation | How to store vectors and run similarity search |
| Best for | Curated, structured, repeatedly used knowledge | Dynamic search over large unstructured corpora | Paraphrased, fuzzy, semantic queries |
| Weakness | File navigation misses once it scales | Needs an index and synchronization | Chunking breaks structure; can retrieve stale chunks |
When OKF alone is enough
If the knowledge is curated, structured, and used repeatedly by an agent — metric definitions, APIs, deployment runbooks, architecture decisions — a directory of markdown plus file navigation is often enough. The corpus is small and the relationships are explicit, so an agent can inspect the path and context directly instead of relying only on embeddings, and you can diff and review it like code.
That is what I did in my own repo: one node each for architecture, decisions, and traps, so Claude and Codex do not re-crawl the whole repo every time. I report the experiment in the last article of this series.
Hands-on: turning a repo into an OKF bundle as agent memoryWhen you still need RAG or a vector database
Once knowledge becomes large, unstructured, and queried in paraphrase, file navigation cannot hold. You cannot ask an agent to traverse a hundred thousand support conversations or an entire document library. That is where the RAG workflow comes in; a vector database is a common retrieval infrastructure for it, using embeddings to find semantically similar content and handle fuzzy queries and synonyms.
OKF does not replace this layer. Its v0.1 spec explicitly says it does not prescribe storage, serving, or querying, and the official docs name a search index as one consumer. You can build a vector index on top of an OKF bundle.
How they work together
A workable arrangement is a division of labor: OKF is the source layer, keeping curated, structured, trusted knowledge in a readable, versionable format; vector/RAG is the retrieval layer, added when you need dynamic search over a large long tail. The agent does a structured lookup first (along OKF paths and links), then a semantic retrieval when needed. That is the subject of the later "OKF + RAG architecture" article in this series.
A practical decision rule
I would not dump the whole company into a vector database on day one. Start simple instead, and let observed retrieval failures decide whether to add complexity.
Start with OKF plus file navigation. Add full-text search (BM25) when navigation starts to miss content. Add a vector index when queries are frequently paraphrased and fuzzy. Consider a formal knowledge graph only when multi-hop relationships become the dominant problem. Let each step be driven by a real failure, not by reaching for the heaviest option first.
That makes "OKF vs RAG vs vector database" a misleading comparison. They operate at three different layers. The more useful question is: which layer is failing right now, and which one should I add?