Manticore Search
Fast, low-footprint database for search
Manticore Search is an open-source, easy-to-use database designed for search. It offers full-text, faceted and vector search with a small memory footprint and SQL-like query syntax.
Key features
- Full-text and vector search
- SQL and HTTP query interfaces
- Low memory footprint
- Real-time indexing
Pros & cons
Strengths
- Lightweight and fast
- SQL-friendly
Trade-offs
- Smaller community than Elasticsearch
Manticore Search replaces
Last reviewed Aug 26, 2026 · 865 words
Manticore Search is what you reach for when you want Elasticsearch-grade full-text search but would rather write SELECT ... WHERE MATCH('...') over a MySQL connection than post JSON to a JVM with 2 GB of heap. It is C++, runs in 256 MB, descends from Sphinx (the fork dates from 2017), carries 12,000 stars and a GPL-3.0 licence, and behaves like a database rather than a search-as-a-service box. That last point is the one to hold onto: it is not the tool for typo-tolerant instant search on a 10,000-product shop, where Meilisearch or Typesense give you a better result in an afternoon. It is the tool for millions of documents, logs, facets, joins and vectors on hardware that would make Elasticsearch weep.
The MySQL protocol changes how you build with it
Manticore listens on 3 ports: 9306 speaks the MySQL wire protocol, 9308 is HTTP with JSON, and 9312 is the binary protocol older Sphinx clients use. The first one is the interesting one, because any language with a MySQL driver already has a Manticore client, and mysql -h 127.0.0.1 -P 9306 gives you a shell to it.
CREATE TABLE docs(title text, body text, tags multi, published timestamp);
INSERT INTO docs(id, title, body, tags, published)
VALUES (1, 'Reverse proxy showdown', 'Caddy, Traefik and nginx compared', (3,7), 1724630400);
SELECT id, title, WEIGHT() AS score
FROM docs WHERE MATCH('@title proxy') AND tags = 3
ORDER BY score DESC LIMIT 10;
Real-time tables accept inserts and are searchable immediately, which is what a self-hoster usually wants. The MATCH() syntax supports field targeting, phrase and proximity operators, and the ranking can be tuned per query. FACET clauses give you the counts-per-category sidebar that shops and archives want, in one query rather than an aggregation tree.
One container, one volume
services:
manticore:
image: manticoresearch/manticore:latest
ports:
- "9306:9306"
- "9308:9308"
volumes:
- ./data:/var/lib/manticore
ulimits:
nofile:
soft: 65536
hard: 65536
restart: unless-stopped
The file-descriptor limit is worth setting up front because the columnar storage opens many files, and the failure when you hit the default is confusing. Backups are handled by the bundled manticore-backup tool, which snapshots the tables consistently while the daemon runs, and replication between nodes exists if you outgrow one box. For a homelab, one box plus a nightly backup of /var/lib/manticore is plenty.
Vectors live in the same table as the text
A column declared as float_vector with knn_type='hnsw' gives you approximate nearest-neighbour search, and the query is a knn() clause in the same SELECT you already use, so hybrid keyword-plus-semantic search is a WHERE MATCH(...) AND knn(...) rather than two systems glued together. You compute the embeddings outside Manticore with whatever model you like and insert them alongside the document. For a personal document search or a RAG pipeline that also needs exact-term matches, that is a tidy setup; the practical guidance on which embeddings to use and how to avoid the common failures is in embeddings search in production.
Where it loses to the instant-search tools
Meilisearch and Typesense make typo tolerance, prefix matching and relevance defaults work with zero tuning, and ship a dashboard. Manticore has fuzzy matching and autocomplete features, but they are options you enable and tune per query rather than the default behaviour, and there is no admin UI in the box. If the job is "search box on a small site that forgives spelling", the instant-search tools win on time to a good result. If the job is "index 20 million log lines or 2 million articles and let people slice them", Manticore wins on memory, on SQL, and on facets. It also accepts Elasticsearch-style JSON writes, so log shippers like Filebeat, Logstash and Vector can feed it, which makes it a lightweight substitute for the ELK stack on a single node. The surrounding choices are laid out in the search category.
The licence question, briefly
GPL-3.0 on a search daemon matters less than it sounds: you talk to it over a network socket, your application does not link against it, and the GPL's copyleft does not reach across that boundary. Anyone weighing it against Elastic's licence terms for a product should read the Elasticsearch alternatives page, but for a homelab or an internal app the licence changes nothing.
What I'd do
For a site search under 100,000 documents, use Meilisearch and move on. Above that, or for anything log-shaped, or when the application already speaks SQL and you want facets and vectors without another service, run Manticore with the compose file above, create real-time tables, and index through the MySQL port from whatever language you already use. Set the file-descriptor limit, run manticore-backup nightly, and give it 1 GB rather than the 256 MB minimum so the columnar cache has room. It is the rare piece of search infrastructure that gets smaller and simpler the more you learn about it.
Compare Manticore Search
28 head-to-head comparisons.
- Manticore Search vs Elasticsearch
- Manticore Search vs Meilisearch
- Manticore Search vs Milvus
- Manticore Search vs Qdrant
- Manticore Search vs Typesense
- Manticore Search vs Sonic
- Manticore Search vs ZincSearch
- Manticore Search vs Weaviate
- Manticore Search vs Tantivy
- Manticore Search vs Quickwit
- Manticore Search vs bleve
- Manticore Search vs Orama
- Manticore Search vs ParadeDB
- Manticore Search vs Lunr.js
- Manticore Search vs Vespa
- Manticore Search vs RediSearch
- Manticore Search vs Pagefind
- Manticore Search vs Marqo
- Manticore Search vs Infinity
- Manticore Search vs Toshi
- Manticore Search vs tinysearch
- Manticore Search vs Stork
- Manticore Search vs Pyserini
- Manticore Search vs Vald
- Manticore Search vs Apache Solr
- Manticore Search vs lnx
- Manticore Search vs Blast
- Manticore Search vs OramaCore
Similar search engines apps
Elasticsearch
Search EnginesDistributed search and analytics engine
Replaces Algolia, Splunk
Meilisearch
Search EnginesFast, typo-tolerant search engine for applications
Replaces Algolia, Elasticsearch
Milvus
Search EnginesOpen-source vector database built for scalable similarity search
Replaces Pinecone, Elasticsearch
SearXNG
Search EnginesPrivacy-respecting metasearch engine aggregating many sources
Replaces Google Search, Bing
Vane
Search EnginesAI-powered search engine, formerly Perplexica
Replaces Google Search
Qdrant
Search EnginesHigh-performance open-source vector search engine
Replaces Pinecone, Algolia