The vector database landscape
There are dozens of vector search products, and the list changes every year. Rather than memorising products, learn the categories — each makes different trade-offs — and then evaluate current options within the category that fits you.
Features, pricing and limits in this space change quickly. Treat the examples below as orientation and always check current documentation before deciding.
1. Dedicated vector databases
Purpose-built for vector search, usually with HNSW and/or IVF, quantization, metadata filtering, hybrid search and horizontal scaling.
| Example | Notes |
|---|---|
| Milvus | Open source, designed for very large scale; managed option available (Zilliz Cloud) |
| Qdrant | Open source, strong filtering and payload indexing; managed cloud available |
| Weaviate | Open source, object-oriented schema, built-in hybrid search and modules; managed cloud available |
| Pinecone | Fully managed service, little to operate |
| Chroma | Developer-friendly, popular for prototypes and smaller applications |
Choose this category when vector search is central to your product, your scale is large, or you need advanced features (heavy filtering, hybrid search, multi-tenancy) at high throughput.
2. Vector search inside databases you already run
Many general-purpose databases and search engines have added vector types and ANN indexes.
| Example | Notes |
|---|---|
| PostgreSQL + pgvector | Vectors next to relational data, full SQL, transactions; widely available on managed Postgres |
| Elasticsearch / OpenSearch | Vector (k-NN) search alongside mature keyword search — natural for hybrid search |
| Redis | In-memory, very low latency, often used alongside caching |
| MongoDB Atlas Vector Search | Vector search over documents in MongoDB's managed service |
| Cloud search services | Managed search products from the major clouds offer vector and hybrid search |
Choose this category when you already operate the database, want one system instead of two, and your scale and latency needs fit within what it can do.
3. Libraries
Not databases — they give you the index algorithms, and you handle storage, updates, filtering, replication and serving yourself.
| Example | Notes |
|---|---|
| FAISS | From Meta; many index types including IVF, PQ and GPU support |
| hnswlib | A compact, fast HNSW implementation |
| Annoy | From Spotify; memory-mapped tree indexes for read-heavy data |
| ScaNN | From Google; efficient ANN with quantization |
Choose this category when you are building your own search service, need full control, or run offline batch jobs (like deduplicating a dataset).
4. Embedded and serverless options
Some tools run inside your application process (like SQLite for vectors), and some managed services are serverless, charging by usage and scaling to zero. Embedded options (for example, LanceDB or Chroma in embedded mode) are great for local tools, notebooks and edge devices; serverless options suit spiky or unpredictable traffic.
What every category shares
All of them implement the same core concepts you've learned: embeddings in, similarity metric, ANN index with a recall–speed trade-off, metadata filtering, and (increasingly) hybrid search. Once you understand those, picking up any specific product takes hours, not weeks.
Choose a category first — dedicated, extension, library, embedded or serverless — based on your scale, your existing stack and how much you want to operate. Then compare the two or three leading options within it on your own data.
Senior Full-Stack Engineer · AI & AWS. I build production search, RAG and AI systems on AWS and Postgres.