This page is for developers and architects adding similarity search to an application, most often to retrieve context for a large language model. The products listed here do the same core job, but they are very different kinds of software, and the type matters more than any single feature. Each listing is labelled with one of five types: a standalone vector database you run or rent as its own server (Weaviate, Milvus, Qdrant, Chroma); a managed vector service with no self-hosted server (Pinecone, Zilliz Cloud); a database extension or feature that adds vectors to a database you may already run (pgvector for PostgreSQL, vector search in Redis 8, MongoDB Atlas and SingleStore); a search engine with vector search (Elasticsearch, OpenSearch, Vespa); and a library embedded in your own process (FAISS, LanceDB).
Several standalone databases also sell a managed cloud (Weaviate Cloud, Qdrant Cloud, Chroma Cloud), and Zilliz Cloud is the managed form of open source Milvus, so check which form a feature belongs to. Two lifecycle notes: Pinecone pod-based indexes are legacy and new organisations use serverless indexes, and LanceDB's documentation now lists only the open source embedded library and LanceDB Enterprise, with the earlier self-serve LanceDB Cloud no longer documented.
What this software does
An embedding model turns text, images or other content into a vector of a few hundred to a few thousand numbers, placed so that similar content lands close together. Vector search finds the stored vectors nearest to a query vector using a distance metric such as cosine similarity, dot product or Euclidean distance. Exact (brute-force) search compares the query with every vector, which is accurate but slows down as the collection grows, so most products build an approximate nearest neighbour (ANN) index that trades a little recall for much lower latency.
The index families a buyer meets are graph indexes such as HNSW (fast and accurate, but usually held in memory), cluster-based IVF indexes, disk-oriented indexes such as DiskANN, and quantization (scalar, product or binary) that compresses vectors to cut memory at some cost in accuracy. Real queries rarely ask for similarity alone: they add metadata filters (tenant, language, date, permissions), and the way filters interact with the index decides whether you get the right number of results. Many products also offer hybrid search, combining keyword (BM25) and vector results with a fusion method such as reciprocal rank fusion (RRF).
The product type sets what you get around the index. A library such as FAISS provides the index and search algorithms only: no persistence layer, metadata storage, access control or replication. A database extension keeps vectors next to relational or document data, with that database's SQL or query language, transactions and backups. A standalone vector database adds its own storage, filtering, multitenancy, replication and APIs. A managed service runs all of that for you, at the cost of control over where and how it runs.
Types of product in this category
- Standalone vector database: A dedicated database server built around vector indexes, with its own storage, filtering and APIs, that you can self-host and that often also has a vendor-run cloud (Weaviate, Milvus, Qdrant, Chroma).
- Managed vector service: A vector database offered only as a hosted service, without a self-managed server edition (Pinecone, with BYOC on Enterprise; Zilliz Cloud, which runs the Milvus engine).
- Database extension or feature: Vector types and indexes added to a general-purpose database, so embeddings sit beside existing data and are queried with its usual language (pgvector, Redis 8, MongoDB Atlas Vector Search, SingleStore).
- Search engine with vector search: A full-text search and analytics engine that added vector fields and kNN queries, strongest when keyword relevance, filters and aggregations matter as much as similarity (Elasticsearch, OpenSearch, Vespa).
- Library: Code you embed in your own application process with no server to run; FAISS provides indexes only, while LanceDB adds tables, persistence on local disk or object storage, and full-text search.
Typical use cases
Retrieval-augmented generation (RAG)
Store chunks of documents, tickets or wiki pages as embeddings and retrieve the closest matches as context for an LLM prompt. Filters on tenant, source and access rights usually matter as much as raw similarity.
Semantic and hybrid site search
Let users search a product catalogue or knowledge base by meaning, combining vector results with keyword matching so exact part numbers and names still rank first.
Recommendations and similar items
Find products, articles or users similar to one the visitor is viewing, using embeddings of content or behaviour.
Duplicate and near-duplicate detection
Flag near-identical support tickets, listings, images or code snippets by distance threshold rather than exact match.
AI features in a multi-tenant SaaS
Keep each customer's vectors separate and searchable at scale. Products differ here: Weaviate uses a shard per tenant, Pinecone uses namespaces, and Qdrant and Milvus document several partitioning patterns.
Image, audio and multimodal search
Search media by example or by text description using multimodal embedding models; check vector dimension limits and memory use for large media collections.
How to choose
- Product type and who operates it. Decide first whether you want a library, an extension to a database you already run, a standalone server or a managed service. If your data already lives in PostgreSQL, pgvector avoids a second system; if you want no servers at all, a managed service such as Pinecone removes index and shard management; FAISS suits teams that will build storage and serving themselves.
- Index options and memory footprint. Check which ANN indexes and quantization methods are offered and where the index lives. HNSW indexes are typically built in memory (Weaviate notes this for its default index), so large self-hosted collections need RAM planning or compression. Milvus documents the widest choice, including DiskANN and GPU indexes; Zilliz Cloud narrows this to AUTOINDEX; Pinecone does not let you choose.
- Filtered search accuracy. Test queries that combine similarity with restrictive filters. With approximate indexes, pgvector applies filters after the index scan, so queries can return fewer rows unless iterative scans are enabled; Qdrant builds filter-aware HNSW links when payload indexes exist before the index is built; FAISS only supports filtering by ID.
- Hybrid and keyword search. If users search for exact names and codes, you need keyword search alongside vectors. Elasticsearch, OpenSearch, Vespa, Weaviate, Qdrant, Milvus and Pinecone document hybrid search; Chroma's hybrid Search API is Chroma Cloud only as of November 2026; pgvector combines with PostgreSQL full-text search in your own SQL.
- Multitenancy and isolation. For SaaS products, check how tenants are separated, how many tenants the design supports and whether access control applies per tenant. Milvus notes that partition and partition-key tenancy do not support RBAC, so strong isolation there needs separate databases or collections.
- Deployment, residency and lock-in. Confirm where data can live. Pinecone is closed source and can run in your own cloud account only through Enterprise BYOC; LanceDB has no documented self-serve cloud plan, only Enterprise; open source servers (Milvus, Qdrant, Weaviate, Chroma, OpenSearch) can be self-hosted anywhere.
- Licence. Licences range from permissive to restrictive: MIT for FAISS; Apache 2.0 for Milvus, Qdrant, Chroma, LanceDB OSS, OpenSearch and the Vespa engine; BSD-3-Clause for most of Weaviate (with a commercially licensed folder); the PostgreSQL License for pgvector; AGPLv3, SSPL or the Elastic License for Elasticsearch; RSALv2, SSPLv1 or AGPLv3 for Redis 8. Review the terms if you embed or host the software for others.
- Cost model. Billing units differ: read and write units (Pinecone), vector dimensions and storage (Weaviate Cloud), data written, stored and queried (Chroma Cloud), compute units (Zilliz Cloud Serverless), or plain infrastructure for self-hosted software. Estimate from your vector count, dimensions and query rate, because unit prices alone are hard to compare.
- API stability and embedding integration. This category changes fast. Pinecone pod-based indexes are legacy, Qdrant 1.19 removed its legacy search endpoints in favour of the Query API, and OpenSearch deprecated its NMSLIB engine. Also check whether the product can call embedding models for you (Weaviate, Elasticsearch semantic_text, Vespa embedders, Pinecone hosted models) or expects you to supply vectors (pgvector, FAISS).