Embedded vector database

An embedded vector database runs in-process with your app — no separate server — using local disk for persistence. Chroma, LanceDB, sqlite-vss, DuckDB-VSS are 2026 embedded options for RAG without operating a dedicated DB.

Dedicated vector DBs (Pinecone, Qdrant, Weaviate, Milvus) run as separate services — pay for hosting, manage uptime, network latency on every query. Embedded vector DBs flip this: the vector store lives inside your app process, queries hit local disk in microseconds, no server to operate. Trade-offs: no horizontal scale beyond one node, weaker concurrency story, manual sharding. The sweet spot is < 10M vectors per node for Chroma, < 1B for LanceDB. Production patterns: embedded for desktop apps (LM Studio, Claude Desktop with personal RAG), edge inference, single-tenant SaaS where each tenant has their own vector store. For multi-tenant cloud at scale, dedicated vector DBs still win.

When to use embedded vector database

• Desktop / edge / single-tenant RAG.
• Prototypes and < 10M-vector apps.

Common mistakes

• Using embedded mode for multi-instance horizontally-scaled web apps — every replica sees different data without external sync.

FAQ

Related terms

• Vector database — A vector database stores embeddings and performs approximate nearest-neighbor search at scale, the persistence layer behind RAG and semantic search.
• pgvector — pgvector is the Postgres extension that adds vector data types, similarity search, and indexes (IVFFlat, HNSW) — turning Postgres into a usable vector database for RAG workloads in 2026.
• ANN index — An ANN (approximate nearest neighbor) index is the data structure inside a vector DB that returns 'almost-best' matches in sub-millisecond time — HNSW, IVF, ScaNN, DiskANN are 2026 popular implementations.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/embedded-vector-db.md.