Meilisearch vs. Manticore: Setting the Record Straight
Hacker News•July 24, 2026•9 min read•1 views
A few days ago, Meilisearch published a comparison of Meilisearch and Manticore Search . We like comparisons — we published our own back in 2023, with benchmarks you can reproduce. And to be fair, parts of the Meilisearch's comparison are accurate and even generous toward Manticore.
But several claims about Manticore are outdated or simply not what you observe when you run the current version. So instead of arguing, we did what we always do: spun up the latest versions of both engines (Manticore Search 28.4.4 and Meilisearch 1.41/1.48) and tested the claims. Every command and response below is real — feel free to copy-paste and check us.
The article introduces Manticore like this:
Manticore Search is an open-source search engine built as a continuation of Sphinx, improving its functionality with full-text search and real-time analytics.
Sphinx already was full-text search, and real-time analytics is a small slice of what's been added since. Here's what "improving its functionality" actually looks like over the years:
"Sphinx plus real-time analytics" undersells that by a wide margin.
Best for: Large-scale projects and teams that need advanced customization, SQL familiarity, and high-performance querying at scale.
And among the cons: "Complex setup: Initial configuration and tuning can be time-consuming."
Here is the entire "complex setup" of Manticore, from zero to searching — three commands, no config files, no schema:
1. Install (and start — the one-line installer launches the service too):
curl https://manticoresearch.com | sh 2. Insert a document. Note there's no table yet — auto-schema creates it from the data:
+-------+--------+----------------+ | Field | Type | Properties | +-------+--------+----------------+ | id | bigint | | | title | text | indexed stored | | color | text | indexed stored | | price | uint | | +-------+--------+----------------+ Now the same task in Meilisearch (we tested both the latest Docker tag, v1.41.0, and the newest release, v1.48.3). Meilisearch's installer downloads a binary into the current directory, which you then run yourself — and in production mode you'll also need to configure a master key before it starts. Adding documents and searching is just as easy as in Manticore — credit where due. But then you try to filter:
curl -s -X POST localhost:7700/indexes/products/search -H "Content-Type: application/json" \ -d '{"q": "backpack", "filter": "price < 6000"}' | jq { "message" : "Index `products`: Attribute `price` is not filterable. This index does not have configured filterable attributes." , "code" : "invalid_search_filter" , "type" : "invalid_request" } Since we were re-checking everything for this post anyway, here's precisely what does and doesn't work out of the box in Meilisearch — each point verified against the docs and a live instance:
None of this is a bug — it's a design trade-off, and each step is one small API call. But it adds up to a model where you declare capabilities attribute by attribute and pay a full, dataset-proportional re-index every time you change your mind. Manticore's model is different: fields have types — text fields are full-text searchable, attributes (numbers, strings, JSON) are filterable, sortable, groupable, and facetable, vectors are KNN-searchable — and every capability of a type is available from the moment of insert. There's no per-attribute capability registry to maintain, and no re-indexing to change how you query. Deep customization — ranking formulas, tokenization, morphology, per-field weights — is absolutely there (the article's pros list is right about that), but it's opt-in, not a prerequisite. Which is why we're not sure "needs advanced customization" is pointing at the right engine.
The article frames Manticore as the choice for "teams with SQL familiarity." SQL support is a distinctive Manticore strength — you can talk to it with any MySQL client, mysqldump , or a BI tool (a capability the comparison's own integrations table marks as "Not supported" in Meilisearch).
But notice what you just read above: the entire quick-start demo was JSON over HTTP. Practically everything in Manticore is available both ways — SQL for those who like it, a JSON API very similar to what Meilisearch and Elasticsearch users are used to. You don't need to write a single line of SQL to use Manticore.
This is our favorite part. The use-cases table in Meilisearch's article rates the two engines on vector search:
Vector search. Meilisearch: Basic vector search. Manticore Search: Better suited for hybrid and advanced setups.
We agree with both columns. Here's what "hybrid and advanced setups" looks like in practice with auto-embeddings — no external embedding pipeline, no API keys, the model downloads automatically:
CREATE TABLE products_ai ( title TEXT, description TEXT, price INT, vector FLOAT_VECTOR KNN_TYPE = 'hnsw' HNSW_SIMILARITY = 'l2' MODEL_NAME = 'sentence-transformers/all-MiniLM-L6-v2' FROM = 'title,description' ); Insert documents as plain JSON — embeddings are generated for you (there's also a /bulk endpoint for batches):
curl -s 0:9308/insert -d '{ "table": "products_ai", "id": 1, "doc": { "title": "green hiking backpack", "description": "Lightweight backpack suitable for hiking trails", "price": 5999 } }' curl -s 0:9308/insert -d '{ "table": "products_ai", "id": 3, "doc": { "title": "trail running shoes", "description": "Lightweight shoes with great grip for trails", "price": 7500 } }' And run a hybrid search — full-text and semantic search fused with RRF — in a single request:
curl -s 0:9308/search -d '{ "table": "products_ai", "hybrid": {"query": "gear for a mountain hike"}, "_source": ["title", "price"], "size": 2 }' | jq { "hits" : { "hits" : [ { "_id" : 1 , "_knn_dist" : 0.88308269 , "_hybrid_score" : 0.01639344 , "_source" : { "title" : "green hiking backpack" , "price" : 5999 } }, { "_id" : 3 , "_knn_dist" : 1.09160841 , "_hybrid_score" : 0.01612903 , "_source" : { "title" : "trail running shoes" , "price" : 7500 } } ] } } No document mentions the word "gear" or "mountain" — that's semantic understanding out of the box, two requests total. Under the hood there's vector quantization to cut RAM usage, KNN prefiltering so filters work inside the HNSW traversal, and continuous KNN performance work . "Better suited for hybrid and advanced setups" — yes, we'll take that.
And you don't have to take our word for it — these live demos all run on Manticore: catalog search with filters, facets, typo tolerance, and semantic search; reverse image search ; and conversational search .
Search-quality claims can be tested empirically. We benchmarked Manticore Search and Meilisearch in full-text, vector, and hybrid modes across 14 public IR dataset/corpus-size groups: seven BEIR datasets, ACORD, MS MARCO Passage at 250K and 8.8M documents, TREC DL 2019/2020, Wayfair's WANDS product-search dataset, and the typo-focused DL-Typo. For each engine/mode pair, we select its best completed run in each group and compute an unweighted average across the groups. The first row then selects each engine's best mode per group before averaging. Vector and hybrid runs use the same Qwen3-Embedding-8B model on both engines. Quality is scored with each dataset's canonical metric: NDCG@10, or MRR@10 for MS MARCO.
Comparing each engine's best result per group, Manticore leads on 11 of the 14. Vector quality is nearly tied at 0.530 and 0.527; both engines use the same embedding model, while their indexing and retrieval implementations still differ. The hybrid results show a wider difference, with Manticore's RRF averaging 0.515 against 0.475.
Full-text has the largest gap: 0.420 against 0.237. The wider benchmark helps explain why. The engines using BM25 or a BM25-family ranker cluster well above Meilisearch in full-text relevance. Meilisearch instead applies an ordered set of rules based on matching words, typos, proximity, attributes, and exactness. It therefore lacks BM25's combination of inverse document frequency, term-frequency saturation, and document-length normalization, which is the main reason it performs poorly on these standard IR datasets. Typesense, another engine in the wider comparison that does not use BM25, shows a similar pattern. Meilisearch's ten-word query limit can hurt longer queries further because the remaining words are ignored.
Manticore also leads on DL-Typo, which focuses specifically on typo robustness.
The same harness also tests Elasticsearch, OpenSearch, Qdrant, Typesense, Vespa, and Weaviate. Some engines could not complete the largest tests with the resources available on the benchmark server, so the report provides two coverage-controlled leaderboards. Recomputed over the ten-group subset covered by all eight engines, Manticore's best-mode average places second overall, behind Qdrant. Across all 14 groups, it also places second among the five engines with complete coverage. Meilisearch records a lower average in both comparisons.
The full comparison already includes coverage, per-dataset tables, and exact per-run configurations. This work is still in progress though. We'll publish the complete methodology and remaining details soon. We'll also release our new benchmarking tool as open source, making benchmarks like this much easier to run and extend.
Manticore is primarily used for complex, large-scale search and analytics workloads that require high performance and deep customization.
And in the use-cases table, Manticore "may be overkill for simple CMS needs."
We checked our anonymized telemetry . Among Manticore instances that report data-size metrics:
So no — Manticore is not primarily used for large-scale workloads. Most real-world Manticore installations are small projects: sites, catalogs, blogs, internal tools. Exactly the "simple CMS needs" the table warns you about. A Manticore container idles at under 200 MB of RAM, and as you saw above, a working search takes three commands — it's hard to call that overkill for anything.
The nice part is that the same engine also holds up at the other end: Locally serves tens of thousands of queries per second on Manticore after migrating from Elasticsearch. Scaling down and scaling up aren't mutually exclusive.
Curiously, the same table gives Manticore a compliment we'd soften ourselves: "Designed for real-time data and analytics." Manticore has solid analytics capabilities — columnar storage , aggregations, Kibana and Grafana integrations, log-pipeline integrations — and it's well-suited for log search . But it is first and foremost a search engine. Analytics is one of its use cases, not what it's "primarily designed" for, and not what most of our users run it for.
We promised facts, and facts cut both ways:
Since this post is a response to Meilisearch's comparison , let's fix its integrations table too. The original lists Go twice with contradictory answers ("supported via commu
Hacker NewsJuly 24, 20269 min read1 views