Vector Database RAG AI Embeddings Databases System Design

Vector Database Map: 15 Options by Ops Model

Core Concept LearningJuly 16, 20269 min readUpdated July 21, 2026

Semantic search, RAG, and agent memory depend on the same primitive: store embeddings and retrieve nearby vectors with the filters your product requires. The market spans managed SaaS, open-source engines, search platforms, and extensions to databases you already run. Types of Databases places vector indexes within the wider storage landscape.

For AI builders choosing a first retrieval store, this guide maps fifteen options by ops model and workload, then follows a support chatbot through upsert and filtered query. Capabilities reflect public product surfaces as of July 2026; re-verify packaging and pricing before rollout. You will leave with a pasteable pgvector baseline and an evidence-based bake-off plan; use How to Choose the Right Database to turn those results into a decision record.

Four lanes of vector storage for AI builders

Learning path

Follow these checkpoints in order — each builds on the last.

Every vendor demo looks like "the one" without this map — with it, an option gets rejected in thirty seconds for the wrong ops model, missing hybrid search, or no path for tenant filters.
A dimension or metric mismatch returns confident wrong neighbors, not an error — pin the embedding model and dimension in config and fail closed, since the symptom looks exactly like a hallucination.
An ANN cluster is not "set and forget" — budget for upgrades, backups, and monitoring the same way you would for Postgres, since a bad rolling upgrade shows up as timeouts and partial recall in production.
Dense vector fields plus HNSW inflate heap enough to cause GC thrash and knn timeouts — size nodes for both inverted and ANN indexes from the start, or a search cluster that already worked starts paging at 2 a.m.
FAISS's durability is your job, not the library's — neighbors vanish after a restart unless the index is persisted, which is exactly why most production RAG systems start on pgvector instead.
A bake-off proves the choice — same embedding model, same doc set, measured recall@k and p95 latency — not a blog ranking, and it has to re-run every time the embedding model changes.
A wrong tenant filter or a model mismatch at the ANN-search step looks exactly like a "RAG hallucination" downstream — the vector DB owns that one step, and logging retrieved chunk IDs is what tells the two apart.

Map the vector database landscape

A vector database indexes high-dimensional embeddings (typically 384–3072 dimensions) so you can ask: which documents are closest to this query vector? Under the hood you will see HNSW, IVF, or product quantization — the product choice matters less at first than ops model, filtering, and how it fits your existing stack.

Group the fifteen options into four lanes before memorizing brand names: managed cloud (Pinecone, Astra DB, Redis Vector), dedicated open-source engines (Milvus, Weaviate, Qdrant, Chroma, LanceDB, Vespa), search platforms with vectors (Elasticsearch, OpenSearch), and libraries / extensions (FAISS, pgvector, Neo4j Vector Index, SingleStore). Same problem; different ownership and scale trade-offs.

If you skip this map, every vendor demo looks like "the one." With the map, you can reject an option in thirty seconds: wrong ops model, missing hybrid search, or no path for tenant filters.

Query path: embed → index → filter → nearest neighbors

Quick reference

Embeddings come from models (OpenAI, Cohere, local sentence-transformers) — the DB stores and searches them.
Payload / metadata filters matter as much as ANN distance for real RAG (tenant, ACL, date).
Hybrid search (keyword + vector) beats pure ANN on exact product names and codes.
Latency targets differ by workload and method: interactive chat retrieval is often tighter than batch analytics or edge/local apps—measure your filter path.
Start with the lane that matches ops capacity — not the logo with the most LinkedIn posts.

Remember this

Every vendor demo looks like "the one" without this map — with it, an option gets rejected in thirty seconds for the wrong ops model, missing hybrid search, or no path for tenant filters.

Managed platforms: ship RAG without running ANN ops

Pinecone is a common managed starting point as of mid-2026: create an index, upsert vectors, query with metadata filters, and scale without babysitting pods. It is built for production semantic retrieval when you want SLAs and less Kubernetes.

Astra DB (DataStax) adds vector search on a Cassandra-based cloud database — useful when you already think in wide-column / multi-region Cassandra patterns and want vectors next to operational data. Redis Vector (Redis vector search / Redis Stack capabilities) keeps embeddings in-memory for ultra-low latency when real-time assistants and session-scoped memory cannot wait on disk-bound indexes.

Pick managed when your bottleneck is shipping features, not tuning ANN. Revisit cost after you know query volume and vector dimensions — managed bills grow with index size and QPS.

Failure / recovery: a dimension or metric mismatch (or a missing tenant filter) returns confident wrong neighbors or empty hits. Symptom: answers cite the wrong tenant or invent IDs. Recover by pinning embedding model + dimension in config, failing closed on mismatch, re-upserting, and re-running the filtered query until tenant-b returns zero rows.

Managed platforms: less ops, faster production RAG

Quick reference

Pinecone — fully managed; strong for rapid semantic retrieval and production AI apps.
Astra DB — cloud-native Cassandra lineage with integrated vector search.
Redis Vector — in-memory similarity for real-time AI experiences and caches.
Trade-off: managed cost and lock-in vs ops savings; export/eval exit paths early.
Good first production choice when your team size is small and RAG is not your core IP.
Official docs: docs.pinecone.io; docs.datastax.com/en/astra-db-serverless/; redis.io/docs/latest/develop/interact/search-and-query/vectors/.

PineconeAstra DBRedis Vector

Remember this

A dimension or metric mismatch returns confident wrong neighbors, not an error — pin the embedding model and dimension in config and fail closed, since the symptom looks exactly like a hallucination.

Open-source engines built for embeddings

Milvus targets enterprise-scale embedding workloads and high-throughput search — the usual pick when volume, GPU indexing, or multi-tenancy dominate. Weaviate is an open-source vector engine with hybrid retrieval and multimodal-friendly design. Qdrant emphasizes payload filtering and precise retrieval under load — popular when every query must combine similarity with hard filters.

Chroma is the lightweight, developer-centric store for experiments and small RAG apps. LanceDB optimizes multimodal pipelines, analytics, and local-first workflows. Vespa is a serving engine for real-time search, recommendations, and AI ranking at scale — think production ranking stacks, not just a side vector table.

Self-host when data residency, cost at high QPS, or custom deployment topology matter. Budget for upgrades, backups, and monitoring the same way you would for Postgres — ANN clusters are not "set and forget."

Failure / recovery: node disk pressure, replica lag, or a bad rolling upgrade shows up as timeouts, partial recall, or mixed index versions. Recover from a known-good snapshot, drain traffic to a healthy replica, and verify filter correctness on a fixed query set before reopening writes. Official docs: milvus.io/docs, docs.weaviate.io, qdrant.tech/documentation, docs.trychroma.com, lancedb.github.io/lancedb/, docs.vespa.ai.

Open-source engines: from prototype to enterprise ANN

Quick reference

Milvus — massive embedding workloads; high-speed AI search at enterprise scale.
Weaviate — hybrid + multimodal semantic search; open-source engine.
Qdrant — payload filtering and precise retrieval for scalable AI ops.
Chroma — lightweight embedding store for prototypes and early RAG.
LanceDB — multimodal / analytics / local-first development.
Vespa — real-time search, recommendations, and AI ranking systems.

MilvusWeaviateQdrantChromaLanceDBVespa

Remember this

An ANN cluster is not "set and forget" — budget for upgrades, backups, and monitoring the same way you would for Postgres, since a bad rolling upgrade shows up as timeouts and partial recall in production.

Search platforms that added vector indexes

If you already run a search cluster, adding vectors can beat standing up a second database. Elasticsearch combines vector retrieval with structured and full-text search — one engine for BM25, filters, aggregations, and kNN. OpenSearch (open-source fork lineage) similarly enables semantic search, vector indexing, and AI-driven discovery on the familiar OpenSearch APIs and plugins.

Use this lane when hybrid relevance and ops familiarity matter more than a purpose-built vector-only UX. Watch resource costs: dense vector fields and HNSW graphs expand heap and disk; size nodes for both inverted indexes and ANN structures.

Teams with mature ELK/OpenSearch skills often win here: same security model, same ingest pipelines, one less system to page at 2 a.m.

Failure / recovery: dense vector fields plus HNSW inflate heap; symptoms are GC thrash, circuit-breaker trips, or knn timeouts. Recover by sizing nodes for both inverted and ANN indexes, reducing concurrent knn fan-out, and confirming hybrid scoring still returns the labeled chunk IDs after the change.

Search platforms: keyword + vector in one cluster

Quick reference

Elasticsearch — vector + full-text + analytics in one search engine.
OpenSearch — open-source search with semantic/vector indexing for AI discovery.
Reuse existing ingest pipelines, security models, and dashboards when possible.
Tune for hybrid: score fusion (RRF, weighted) beats naive “vector only” for many corpora.
Not ideal if you only need a thin embedding store with no keyword search.
Official docs: www.elastic.co/docs; opensearch.org/docs.

ElasticsearchOpenSearch

Remember this

Dense vector fields plus HNSW inflate heap enough to cause GC thrash and knn timeouts — size nodes for both inverted and ANN indexes from the start, or a search cluster that already worked starts paging at 2 a.m.

Libraries and extensions inside databases you know

FAISS (Meta) is a library, not a full database — it gives efficient similarity indexes over dense embeddings you manage in process or beside your own storage. Ideal for research, custom pipelines, and when you control lifecycle entirely.

pgvector turns PostgreSQL into a vector-capable store: keep rows, joins, and ACLs, add embedding columns and similarity queries — the pragmatic default for many SaaS apps already on Postgres. Neo4j Vector Index pairs graph relationships with semantic retrieval for knowledge-graph RAG. SingleStore is a distributed SQL platform that runs vector ops alongside transactional and analytical workloads — one engine when HTAP + vectors matter.

Extensions win when operational simplicity beats best-in-class ANN features. Many production RAG systems start on pgvector and only split out when recall, scale, or multi-modal needs force a dedicated engine.

Failure / recovery: missing extension, wrong vector(n), or FAISS index held only in process memory. Symptom: SQL errors on upsert/query, or neighbors vanish after restart. Recover with CREATE EXTENSION, migrate/re-embed to the pinned dimension, and persist the library index (or accept that FAISS durability is your job).

Libraries and extensions inside familiar databases

Quick reference

FAISS — Meta's indexing library for efficient similarity matching (not a managed DB).
pgvector — PostgreSQL extension; native vector similarity in relational workflows.
Neo4j Vector Index — graph + semantic AI retrieval together.
SingleStore — distributed SQL with vectors next to OLTP/OLAP.
Choose extensions when operational simplicity beats best-in-class ANN features.
Official docs: github.com/facebookresearch/faiss; github.com/pgvector/pgvector; neo4j.com/docs; docs.singlestore.com.

FAISSpgvectorNeo4j Vector IndexSingleStore

Remember this

FAISS's durability is your job, not the library's — neighbors vanish after a restart unless the index is persisted, which is exactly why most production RAG systems start on pgvector instead.

Decide with a workload checklist

Walk the decision in order: (1) Do you already have Postgres or Elasticsearch? Prefer pgvector or Elasticsearch/OpenSearch for v1. (2) Need managed SLAs with minimal ops? Pinecone (or Astra DB if Cassandra is home). (3) Need open-source control at scale? Milvus, Weaviate, or Qdrant. (4) Prototyping locally? Chroma or LanceDB. (5) Real-time memory / ultra-low latency? Redis Vector. (6) Graph + vectors? Neo4j. (7) Custom ANN in your process? FAISS. (8) Serving + ranking at web scale? Vespa. (9) SQL + analytics + vectors? SingleStore.

Prove the choice with a bake-off: same embedding model, same 10k–100k docs, measure recall@k, p95 latency, filter correctness, and ops hours — not blog rankings. Re-run the bake-off when you change embedding models; dimensions and distance metrics can invalidate old indexes.

Official source notes (checked July 2026): capability claims track public product docs — docs.pinecone.io, milvus.io/docs, docs.weaviate.io, qdrant.tech/documentation, www.elastic.co/docs, opensearch.org/docs, github.com/pgvector/pgvector. Packaging, pricing, and managed defaults change; re-verify before rollout.

Decision path: reuse stack → managed → specialty

Quick reference

Always measure hybrid recall on your queries, not public leaderboards.
Budget for re-embedding when you change models — index rebuilds are real work.
Enforce tenant and auth filters in the DB query, not only in the LLM prompt.
Plan an export path (IDs + vectors + metadata) before you scale spend.
Practice: index one doc set in pgvector and one managed/open-source option; compare.

Remember this

A bake-off proves the choice — same embedding model, same doc set, measured recall@k and p95 latency — not a blog ranking, and it has to re-run every time the embedding model changes.

Zoom into one RAG query

Trace a single support question: embed with the same model you indexed with → ANN search with tenant/ACL filters → return chunk text + scores → stuff into the LLM prompt → answer. The vector DB owns step three; wrong filters or a model mismatch here look like “RAG hallucinations” when the real bug is retrieval.

When to use a dedicated vector DB: millions of vectors, heavy hybrid search, or managed SLAs. When pgvector is enough: you already run Postgres and traffic is moderate. When not to: keyword search alone solves the product — add vectors later.

Zoom: one RAG query — embed → ANN+filter → LLM

Quick reference

Same embedding model for index and query — dimension mismatches fail loudly; semantic drift fails quietly.
Enforce tenant filters in the DB query, not only in the prompt.
Log retrieved chunk IDs in production so you can debug bad answers.
Re-embed when you change models; old indexes become wrong neighbors.
Practice: time one filtered query in pgvector and one in Chroma on the same corpus.

pgvector setup and upsert — SQL

1-- Assumes PostgreSQL with pgvector available.2CREATE EXTENSION IF NOT EXISTS vector;3CREATE TABLE IF NOT EXISTS support_chunks (4  id text PRIMARY KEY,5  tenant_id text NOT NULL,6  content text NOT NULL,7  embedding vector(3) NOT NULL8);9 10INSERT INTO support_chunks (id, tenant_id, content, embedding)11VALUES ('doc-1', 'tenant-a', 'Reset a locked account', '[0.10,0.20,0.30]')12ON CONFLICT (id) DO UPDATE SET13  content = EXCLUDED.content,14  embedding = EXCLUDED.embedding;

Filtered nearest-neighbor query

1-- Query embedding must use the same model and dimensions.2SELECT id, content, embedding <=> '[0.11,0.19,0.29]' AS distance3FROM support_chunks4WHERE tenant_id = 'tenant-a'5ORDER BY embedding <=> '[0.11,0.19,0.29]'6LIMIT 3;7 8-- Expected first row: doc-19-- Verification: change tenant_id to tenant-b; expect zero rows.

Remember this

A wrong tenant filter or a model mismatch at the ANN-search step looks exactly like a "RAG hallucination" downstream — the vector DB owns that one step, and logging retrieved chunk IDs is what tells the two apart.

Key takeaway

The fifteen products cover managed SaaS, open-source engines, search platforms, and libraries or extensions. You need one lane that matches your operating capacity and one bake-off on your data—not every logo.

Practice (30 min): paste the two SQL panels into a pgvector-enabled Postgres database. The baseline passes when doc-1 is the first result for tenant-a and no row leaks for tenant-b. Then load 50–200 real chunks into this baseline and one alternative, run the same ten labeled queries, and record recall@3, p95 latency, filter failures, and setup time. Choose only after writing an explicit threshold for switching away from pgvector.