Retrieval infra
Use this page when your application needs a reliable place to store embeddings, run similarity search, filter results, and support retrieval at scale.
Search layer
These projects sit behind RAG systems, semantic search products, recommendation features, and other embedding-heavy workloads.
Not the chat app
A vector database stores and retrieves data. It usually works alongside an app, framework, model runtime, and ingestion pipeline.
Why it works
Operational vector stores
Qdrant, Chroma, Weaviate, Milvus, LanceDB, Marqo, and Vespa are common choices when you need metadata filtering, predictable APIs, and retrieval-specific operations.
Search engines and hybrid retrieval
Typesense, Meilisearch, Elasticsearch, and OpenSearch fit teams that need keyword search, filters, facets, and vector or hybrid search together.
Embedded and database-native retrieval
pgvector, pgvectorscale, and sqlite-vec keep vector search close to application data when adding another service is not worth the operational cost.
Curated repositories
qdrant
Qdrant - High-performance, massive-scale Vector Database and Vector Search Engine for the next generation of AI. Also available in the cloud https://cloud.qdrant.io/
chroma-core
Data infrastructure for AI
weaviate
Weaviate is an open-source vector database that stores both objects and vectors, allowing for the combination of vector search with structured filtering with the fault tolerance and scalability of a cloud-native database.
milvus-io
Milvus is a high-performance, cloud-native vector database built for scalable vector ANN search
lancedb
Developer-friendly OSS embedded retrieval library for multimodal AI. Search More; Manage Less.
pgvector
Open-source vector similarity search for Postgres
typesense
Open Source alternative to Algolia + Pinecone and an Easier-to-Use alternative to ElasticSearch ⚡ 🔍 ✨ Fast, typo tolerant, in-memory fuzzy Search Engine for building delightful search experiences
meilisearch
A lightning-fast search engine API bringing AI-powered hybrid search to your sites and applications.
elastic
Free and Open Source, Distributed, RESTful Search Engine
opensearch-project
🔎 Open source distributed and RESTful search engine.
vespa-engine
AI + Data, online. https://vespa.ai
marqo-ai
Ecommerce Search and Discovery - marqo.ai
asg017
A vector search SQLite extension that runs anywhere!
timescale
Postgres extension for vector search (DiskANN), complements pgvector for performance and scale. Postgres OSS licensed.
Selection guide
Choose based on deployment model, filtering, hybrid search, scale, and whether retrieval should live in a standalone service or inside an existing database.
Standalone vector databases
Qdrant, Weaviate, Milvus, Marqo, and Vespa are stronger fits when retrieval needs a dedicated service with scaling and operational controls.
Developer-friendly retrieval layers
Chroma, LanceDB, and sqlite-vec can be easier to start with for local apps, notebooks, embedded retrieval, or multimodal workflows.
Postgres-first stacks
pgvector and pgvectorscale fit when embeddings should stay with relational data, SQL, joins, and existing Postgres operations.
Search engines with vector support
Typesense, Meilisearch, Elasticsearch, and OpenSearch fit teams that need full-text, filters, facets, and vector or hybrid search in the same retrieval layer.
Retrieval quality
For RAG and semantic search, ranking quality often depends on filtering, full-text search, sparse vectors, reranking, and metadata design, not only nearest-neighbor speed.
RAG backends
Look for reliable indexing, predictable APIs, language SDKs, backup options, and observability around retrieval behavior. Dedicated vector stores and search engines solve different parts of the same retrieval problem.
Operations
A small private assistant may not need a distributed vector database. Larger retrieval products may need replication, sharding, RBAC, multi-tenancy, Kubernetes support, and backup plans.
Lower ops burden
Chroma, LanceDB, sqlite-vec, or pgvector can be simpler when scale is modest or the team already runs Postgres or SQLite.
Higher scale
Milvus, Weaviate, Qdrant, Vespa, Elasticsearch, and OpenSearch are better fits when retrieval becomes a dedicated production service.
Suggested additions
Apache Solr
apache/solr
A mature search engine with dense vector search, filtering, and hybrid retrieval patterns. Strong candidate when search infrastructure matters as much as vector similarity.
View repositoryInfinity
infiniflow/infinity
An AI-native database and search engine with dense, sparse, tensor, full-text, and hybrid search. Promising fit, but newer than the established search and vector database options.
View repositoryRediSearch
RediSearch/RediSearch
Adds full-text, vector similarity, and filtering capabilities to Redis. Useful for Redis-heavy stacks, with licensing and Redis version details to review before adoption.
View repositoryParadeDB
paradedb/paradedb
A Postgres-native search and analytics project with a strong retrieval story. Keep suggested until its vector and hybrid-search positioning is clearly registry-worthy for this page.
View repositoryVald
vdaas/vald
A Kubernetes-native distributed vector search engine. Relevant for ANN service deployments, but heavier and less broad than the main curated options.
View repositoryOrama
oramasearch/orama
A lightweight search engine with full-text, vector, and hybrid search for browser, server, and edge use. Better as an embedded search layer than a classic vector database.
View repositoryNucliaDB
nuclia/nucliadb
An AI search database for RAG and unstructured data. Relevant to retrieval storage, but lower-adoption and more specialized than the main list.
View repositoryHelixDB
HelixDB/helix-db
A newer graph-vector database project. Interesting for graph-plus-vector retrieval, but still early compared with established vector and search infrastructure.
View repositoryRelated pages
Self-hosted ChatGPT alternatives
Chat interfaces and assistant apps you can run with local models, private endpoints, or your own hosted providers.
Local model runtimes and inference servers
Inference servers and local runtimes for serving models on your machine, server, or private cloud.
Self-hosted RAG tools
Knowledge-base apps, retrieval frameworks, and document pipelines for private data and production AI systems.
Agents, workflows, and app builders
Agent frameworks, workflow engines, and app builders for repeatable AI-powered processes.
AI developer tools
Coding assistants and repo-aware tools that can run locally or inside private development environments.
FAQ
It stores embeddings and supports similarity search, filtering, and retrieval for RAG, semantic search, and recommendation features.
No. Some stacks use Postgres with pgvector or hybrid search layers. A dedicated vector store helps when retrieval scale, filtering, or operational separation matters.
It can be, especially for Postgres-centric products that need SQL, joins, transactions, and simpler operations. Dedicated vector databases can be better when retrieval needs separate scaling, multi-tenancy, or specialized vector operations.
For many small or Postgres-heavy deployments, pgvector has the lowest extra operational burden. sqlite-vec is useful for embedded SQLite workflows. Chroma and LanceDB can also be simpler for local or embedded retrieval. Qdrant, Weaviate, Milvus, Vespa, Elasticsearch, and OpenSearch fit better as dedicated services.
They are better described as search engines with vector or hybrid retrieval support. They belong here when the job is semantic retrieval with keyword search, filtering, facets, and ranking in the same layer.
