Open Source Search Engine
Search looks like a solved problem until you run it on your own data and hit the truth that relevance is a thousand small decisions, from how a typo is forgiven to which fields outrank others to whether a plural matches a singular, that a hosted search box quietly makes for you. Open source engines put that ranking logic back in your hands and run on hardware you control, so results answer to your judgment about what matters rather than a vendor's defaults and per-query bill. The catch is that the same freedom makes indexing, analyzers, and failure recovery your job, which is why the right engine depends less on a feature list than on the shape of your data and how people actually ask for it.
Elasticsearch
Distributed RESTful search and analytics engine with vector search and near real-time indexing
Meilisearch
Open-source search engine API for hybrid full-text and semantic search in apps and websites
Milvus
Cloud-native vector database for scalable ANN search, hybrid search, and real-time updates
Khoj
Self-hostable AI second brain for chat, semantic search, agents, and research across your docs and the web
Qdrant
Vector database and search engine for semantic search with payload filtering, hybrid search, and distributed deployment
SearXNG
Free internet metasearch engine that aggregates results without tracking or profiling users
Chroma
Open-source search infrastructure for AI with in-memory prototyping and optional persistence
Typesense
Typo-tolerant search engine for search-as-you-type, full-text, geo, semantic, and vector search
Sonic
Schema-less search backend that returns identifiers through a lightweight TCP protocol
Our picks
These span the main jobs here, from lightweight app search to vector retrieval and search at scale.
Fast app search with minimal tuning: Meilisearch Meilisearch delivers search-as-you-type with typo tolerance that works out of the box, plus filtering, faceting, sorting, synonyms, and geosearch over a REST API. Hybrid search blends semantic and full-text matching when you need it, and you can self-host it or use Meilisearch Cloud, a low-friction way to add relevant search to a site or app.
Vector search for semantic and RAG: Qdrant Qdrant stores points as vectors with JSON payloads, so semantic similarity can combine with full-text, numeric, geo, and boolean filters in one query. It supports dense, sparse, and multivector search with RRF and DBSF fusion, and runs in a container, on its cloud, or embedded in your process with Qdrant Edge.
Open full-text and analytics at scale: OpenSearch OpenSearch is a distributed, RESTful engine covering full-text and vector search plus dashboards and observability in one suite. Forked from Elasticsearch and Kibana, it stays fully open under Apache 2.0 and is governed by the OpenSearch Software Foundation, which makes it a strong choice when you want scale and an unambiguous open license.
SQL-first search for existing stacks: Manticore Search Manticore Search is a search-focused database you query with SQL over the MySQL protocol, so MySQL clients can talk to it directly. It handles full-text search with ranking, faceting, fuzzy matching, and highlighting, combines full-text and vector retrieval in one hybrid query, and adds real-time inserts and multi-master replication.
Fitting a search engine to your corpus
The engines gathered here answer very different questions, so the first cut is what kind of search you mean. Classic full-text engines built on inverted indexes, like Elasticsearch, OpenSearch, Solr, Typesense, and Meilisearch, are the right default for keyword queries, facets, filters, and sorted result pages. Vector databases like Qdrant, Milvus, Weaviate, and Chroma exist for semantic matching, where users describe a concept in words the document never uses. A few, such as Manticore Search and Weaviate, do both in one hybrid query. And some listings are not general search at all: Pelias and Photon geocode addresses, SearXNG aggregates other engines, and Khoj and SurfSense put search behind an LLM.
For keyword search, test the analyzers against your real text before anything else, because stemming, synonyms, tokenization, stop words, and typo tolerance decide result quality far more than the demo dataset does. Then treat indexing as a pipeline you run daily: where the source of truth lives, how deletes propagate, how fast a change becomes searchable, and whether a schema change forces a full reindex. Large catalogs, log archives, and document stores stress different parts, from bulk ingest throughput to incremental updates to retention, so favor engines that make failed ingestion recoverable through stable document IDs and give you clear visibility into refresh lag.
Before search reaches users, make sure you can debug it. You want tooling to inspect why a document matched, compare ranking before and after an analyzer change, and roll back a bad synonym set. For production, look closely at clustering, snapshots, and behavior under memory pressure, and if results are permissioned, treat document-level access as core architecture rather than an application-layer filter bolted on later.
Related categories
Frequently asked questions
Should I use keyword search, vector search, or hybrid?+
Keyword search stays the right default for exact terms, identifiers, filters, facets, and ranking you can explain, and Meilisearch, Typesense, Solr, and OpenSearch all do it well. Vector search helps when users describe a concept in different words than the document uses, which is where Qdrant, Milvus, Weaviate, and Chroma fit. Hybrid search combines both but adds embeddings, model drift, and ranking fusion to maintain, so choose it only when semantic recall clearly earns the extra pipeline.
Which of these are search engines and which are vector databases?+
Meilisearch, Typesense, ZincSearch, Manticore Search, Solr, Elasticsearch, and OpenSearch are full-text engines that match words and rank documents. Qdrant, Milvus, Weaviate, and Chroma are vector databases that find nearest neighbors among embeddings. Sonic is a lightweight identifier index that returns IDs for your database to resolve. Several overlap, since Weaviate, Manticore, and Elasticsearch all offer both keyword and vector search, so the label matters less than which query you run most.
What is the lightest engine for adding search to a small app?+
Meilisearch and Typesense are built for exactly this, with typo tolerance and search-as-you-type working out of the box and little to tune. ZincSearch runs as a single binary on a fraction of Elasticsearch's resources and speaks Elasticsearch-compatible ingestion APIs. Sonic goes lighter still, returning identifiers over a simple TCP protocol for your database to resolve. Any of these avoids the operational weight of a full distributed cluster.
How do OpenSearch and Elasticsearch relate?+
OpenSearch is a fork of Elasticsearch and Kibana that AWS created in 2021, after Elastic moved those products off the Apache 2.0 license. OpenSearch stays fully open under Apache 2.0 and is now governed by the OpenSearch Software Foundation under the Linux Foundation. The two share deep roots and remain broadly similar for full-text and vector search, but their APIs and features have drifted, so test against your own workload rather than assuming drop-in parity.
Are the geocoders like Pelias and Photon really search engines?+
They are specialized search: both turn addresses and place names into coordinates and reverse-geocode coordinates back into places, and both build on a general engine underneath, Pelias on Elasticsearch and Photon on OpenSearch. If your problem is address lookup, map search, or location autocomplete, a geocoder handles the language handling and OpenStreetMap data a general index would make you build yourself. For arbitrary documents, use a general full-text engine instead.
Do I need something like Sentence Transformers to run semantic search?+
You need a way to turn text into embeddings, and Sentence Transformers is a common one: a Python framework that computes embeddings and reranks results using thousands of pretrained models. The vector database then stores and searches those embeddings. Some engines fold embedding in, since Weaviate can vectorize at import time and Chroma handles tokenization, embedding, and indexing for you, so you may not run a separate framework at all.
What happens if an open source search engine project stalls?+
Your exit risk depends on how much of your system is tied to its query language, mapping format, plugins, and scoring behavior. Keep the raw documents outside the index in a database or object store, version your schema, and avoid depending on obscure extensions unless they earn the lock-in. If the project slows, you can usually keep running it for a while; the real pressure points are security fixes and client-library compatibility, so those are what to watch.