Vector DBs

A vector database is a system whose primary query is similarity in a high-dimensional embedding space: given a query vector, return the nearest stored vectors (and their payloads) under a chosen metric (usually cosine or L2). That job is distinct from a document store, a relational OLTP engine, or an agent framework. In this catalog the cell sits under Infrastructure, beside Knowledge Graphs: graphs answer typed relationship questions; vector DBs answer “what looks like this?” at scale.

Under the hood the hard problems are indexing and filtered search. Brute-force scan works for toys; production packs expose ANN indexes (HNSW, IVF, disk-backed variants), quantization, sharding, and metadata filters so “nearest” is constrained by tenant, project, time, or ACL. Hybrid retrieval (sparse + dense) shows up when keyword precision still matters. None of that is RAG by itself — RAG owns ingest, chunking, and the generate loop that consumes these hits — and it is not Memory, which is about durable facts and episodes across sessions rather than a raw embedding table.

This research cut currently holds nine packs. They span different operational bets:

• FAISS is the library-shaped extreme: blazingly studied ANN primitives you embed in your own process, with no opinionated multi-tenant service.
• pgvector keeps vectors next to relational truth — useful when the company model already lives in Postgres and you refuse a second system of record for “just embeddings.”
• Chroma and LanceDB optimize for developer-local and embedded workflows: short path from notebook to collection, less ops surface.
• Qdrant, Milvus, and Weaviate are service-shaped open-core stores aimed at filtered, large-scale similarity with APIs agents and pipelines can call.
• OpenSearch and marqo sit closer to search platforms: vectors as one retrieval mode inside a broader index/query product.

When evaluating a member for an agentic OS, ask operational questions, not logo questions: Can filters express the company’s tenancy and case boundaries? Can deletes and updates keep the index honest when evidence changes? Is the latency budget compatible with online tool calls? Does the pack force a second truth store you will eventually have to reconcile? Prefer pgvector when relational locality wins; prefer a dedicated engine when ANN scale and filter performance are the bottleneck; prefer FAISS when you are building a custom retrieval runtime and accept ownership of durability.

Boundaries matter for wiki navigation. Reach for RAG when the missing piece is corpus grounding and citation. Reach for Memory when the missing piece is cross-session state. Reach for Knowledge Graphs when cosine neighbors cannot express “why these entities connect.” Stay in Vector DBs when the missing piece is embedding storage and similarity search itself — the substrate packs like Qdrant and Milvus provide so higher layers do not reinvent ANN.

Feature maps from these packs already point at retrieval and persistence concerns such as Knowledge Grounding & RAG and Memory & State Persistence: the vector store is how those features get durable, queryable substrate — it is not a substitute for the feature’s product contract.