Quick answer:
A vector database stores embeddings (the number-lists AI models use to represent meaning) and answers one question extremely fast: “which stored items are most similar to this one?” That nearest-neighbor search over millions of vectors is the backbone of semantic search and RAG, and doing it in milliseconds takes special indexes that ordinary databases historically didn’t have.
The category boomed with ChatGPT, then got crashed by an inconvenient fact: regular databases learned the trick.
What is a vector database?
A normal database finds exact matches: WHERE email = 'x'. A vector query is fuzzier: “here are 1,536 numbers, find the 10 stored rows whose numbers point in the most similar direction”. Comparing against every row (brute force) works fine at 100,000 vectors and falls over at 100 million.
The fix is approximate nearest neighbor (ANN) indexing. Algorithms like HNSW (a graph you hop through, greedily moving toward closer neighbors) and IVF (cluster the space, search only promising clusters) trade a sliver of accuracy for orders-of-magnitude speed. You might get 9.9 of the true top 10, a thousand times faster. For search and RAG, that trade is nearly always right.
A real vector database wraps those indexes with the boring necessities: metadata filtering (“similar to this, but only docs from 2025 tagged ‘contracts'”), updates and deletes without rebuilding the index, hybrid search combining vectors with keywords, and scaling.
Who are the players?
Three camps:
- Dedicated vector databases: Pinecone (managed, closed source, the brand name of the 2023 boom), Weaviate, Qdrant, Milvus, and Chroma (the lightweight developer favorite for prototypes).
- Existing databases with vector support: Postgres via the pgvector extension, plus Elasticsearch, OpenSearch, Redis, MongoDB, ClickHouse.. essentially everyone by now.
- The warehouses: Snowflake, BigQuery, and Databricks all ship vector search, aimed at teams that want RAG over data already sitting in the warehouse.
Do you need a dedicated one?
The default answer in 2026 is start with pgvector. If your app already runs Postgres, adding a vector column costs nothing, keeps vectors next to the data they describe (one query, no sync pipeline), and handles millions of vectors comfortably on decent hardware. A large share of production RAG systems run exactly this and their users never notice.
Dedicated databases earn their keep at the edges: hundreds of millions of vectors, strict latency targets at high query volume, heavy filtered search where naive setups degrade, or teams that want the operational problem to be someone else’s (that’s Pinecone’s actual pitch). Those are real cases; they’re just rarer than the 2023 funding suggested.
The evaluation trap to avoid: benchmarking on recall alone. Filtering behavior, index rebuild cost, and what happens during updates are where these systems differ in production.
What are the benefits and drawbacks of a dedicated vector database?
Benefits of a dedicated vector database
Built for the one query that matters
ANN indexes, filtered search, and hybrid retrieval are the whole product, tuned by people who do nothing else. At hundreds of millions of vectors with tight latency targets, that focus shows.
Scale is someone else’s pager
Managed offerings handle sharding, replication, and index rebuilds. For teams without infrastructure appetite, “it’s an API” is the actual feature.
Filtering that survives contact with production
Real queries are “similar to this AND tenant = X AND date > Y”, and naive implementations fall apart there. The dedicated engines invested exactly where it hurts.
Fast-moving feature edge
Hybrid search, built-in embedding, rerankers, namespaces for multi-tenancy: the specialists ship retrieval features quarters before general databases bolt them on.
Drawbacks of a dedicated vector database
Your data just split in two
Vectors live there, source records live in your real database, and you now maintain the sync between them. Every architecture diagram grows an arrow, and every arrow is a job.
pgvector ate the middle of the market
Millions of vectors on Postgres you already run, with joins and transactions included, covers most actual workloads. The dedicated tier starts where that stops, which is further out than the pitch decks admit.
Young category, real churn
Pricing models, APIs, and vendors themselves have been reshuffling since 2023. Migration between vector stores is unglamorous work that several teams we know have now done twice.
Costs scale with dimensions times rows
Memory-hungry indexes on high-dimensional vectors get expensive quietly. Quantization and dimension trimming help, at a measured cost in recall.
What happened to the vector database gold rush?
2023: ChatGPT lands, every AI app needs retrieval, Pinecone raises $100M at $750M valuation, and “vector database” becomes a category with a dozen funded startups. 2024 onward: pgvector matures, every incumbent database ships vector search, and it becomes clear vectors are a feature more often than a product.
The dedicated vendors responded by climbing the stack: managed retrieval pipelines, built-in embedding and reranking, “RAG as a service” rather than raw vector storage. The lesson generalizes across this whole directory: single-primitive infrastructure either becomes a platform or becomes a checkbox in someone else’s.
Where does it fit in a data stack?
Treat it as one more destination in your pipeline: documents flow in, get chunked and embedded (that’s a transformation step like any other), land in the vector store, and get retrieved at query time. The same hygiene applies as everywhere else in the stack: track what model produced the vectors, monitor freshness (stale embeddings are the vector world’s silent failure), and plan for the day you re-embed everything.
Which is to say: it’s a database. The geometry inside is exotic; the operational duties around it are the same ones this glossary keeps repeating.