# Meilisearch vs Manticore: Setting the Record Straight Meilisearch published a comparison of Meilisearch and Manticore Search. We tested the claims against the latest versions of both engines — here's what a fresh look shows, with reproducible commands. A few days ago, Meilisearch published [a comparison of Meilisearch and Manticore Search](https://www.meilisearch.com/blog/meilisearch-vs-manticore). We like comparisons — we [published our own](/blog/manticoresearch-vs-meilisearch/) 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. ## "Full-text search and real-time analytics" — that's maybe 1% of it 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: - **[RT mode](/blog/rt_vs_plain_mode/)** — Sphinx had RT indexes, but now the whole engine runs without config files: `CREATE TABLE`, insert, and search on the fly - **[Replication](/blog/mike-replication/)** — Galera-based synchronous cluster replication - **A full HTTP JSON API** — nearly everything SQL can do, plus Elasticsearch-compatible bulk endpoints - **[Auto-schema](/blog/create_table/)** — insert data without creating a table first - **[Vector search](/blog/vector-search-deep-dive/)** with [auto-embeddings](/blog/auto-embeddings/), [quantization](/blog/quantization/), and [filtered KNN](/blog/knn-prefiltering/) - **[Hybrid search](/blog/hybrid-search/)** — full-text + semantic fused with Reciprocal Rank Fusion in one query - **[Fuzzy search](/blog/new-fuzzy-search-and-autocomplete/) and [autocomplete](/blog/autocomplete-the-predictive-search/)** — typo tolerance, keyboard-layout awareness, suggestions - **[Columnar storage](/blog/mcl/)** and secondary indexes — for datasets larger than RAM - **[Sharded tables, authentication, and conversational search](/blog/manticore-search-27-1-5/)** - **[Kafka integration](/blog/integration-with-kafka/)**, [Kibana](/blog/kibana-demo/) and [Grafana](/blog/grafana-dashboard-docker/) support, an [MCP server](/blog/mcp-manticore-server/) for AI assistants "Sphinx plus real-time analytics" undersells that by a wide margin. ## "Complex setup" and "advanced customization"? Let's count commands The article's verdict on Manticore: > 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](/blog/one-line-installer/) launches the service too):** ```bash curl https://manticoresearch.com | sh ``` **2. Insert a document. Note there's no table yet — [auto-schema](/blog/create_table/) creates it from the data:** ```bash curl -s 0:9308/insert -d '{ "table": "products", "doc": {"title": "yellow travel backpack", "price": 4990, "color": "yellow"} }' | jq ``` ```json { "table": "products", "id": 8938969113712132097, "created": true, "result": "created", "status": 201 } ``` **3. Search — full-text match plus a filter on a numeric field, immediately:** ```bash curl -s 0:9308/search -d '{ "table": "products", "query": {"bool": {"must": [ {"match": {"*": "backpack"}}, {"range": {"price": {"lt": 6000}}} ]}} }' | jq ``` ```json { "took": 0, "timed_out": false, "hits": { "total": 1, "total_relation": "eq", "hits": [ { "_id": 8938969113712132097, "_score": 1356, "_source": { "title": "yellow travel backpack", "color": "yellow", "price": 4990 } } ] } } ``` Everything is queryable the moment it lands in the table: text fields are full-text searchable — per-field too, e.g. `{"match": {"color": "yellow"}}` — and attribute fields like `price` are filterable, sortable, groupable, and facetable, with no declarations and no re-indexing. Here's the schema Manticore inferred on its own: ``` +-------+--------+----------------+ | 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: ```bash curl -s -X POST localhost:7700/indexes/products/search -H "Content-Type: application/json" \ -d '{"q": "backpack", "filter": "price < 6000"}' | jq ``` ```json { "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: - **Searching works immediately.** By default `searchableAttributes` is `["*"]` — every field of every document is searchable, no declarations needed. - **Filtering doesn't.** Fields must first be declared in `filterableAttributes`. [Meilisearch's documentation](https://www.meilisearch.com/docs/learn/filtering_and_sorting/filter_search_results) is upfront about the cost: *"This step is mandatory and cannot be done at search time. … Updating `filterableAttributes` requires Meilisearch to re-index all your data, which will take an amount of time proportionate to your dataset size and complexity."* - **Faceting doesn't either.** Facets are built on the same `filterableAttributes` list, so the same declare-and-reindex step applies. In Manticore, [faceted search needs no manual filter building](/blog/faceted-search-without-manual-filter-building/) at all. - **Sorting doesn't.** [Per Meilisearch's docs](https://www.meilisearch.com/docs/learn/filtering_and_sorting/sort_search_results): *"To allow your users to sort results at search time you must … add those attributes to the `sortableAttributes` index setting."* - **Tuning search fields re-indexes too.** The order of `searchableAttributes` determines relevancy, so restricting or re-ordering it is a step most real projects take — and *"updating `searchableAttributes` triggers a re-indexing of all documents in the index."* 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. ## "SQL familiarity" — optional, not required 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. ## Vector search: Meilisearch's own table says it best 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](/blog/auto-embeddings/) — no external embedding pipeline, no API keys, the model downloads automatically: ```sql 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): ```bash 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](/blog/hybrid-search/) — full-text and semantic search fused with RRF — in a single request: ```bash curl -s 0:9308/search -d '{ "table": "products_ai", "hybrid": {"query": "gear for a mountain hike"}, "_source": ["title", "price"], "size": 2 }' | jq ``` ```json { "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](/blog/quantization/) to cut RAM usage, [KNN prefiltering](/blog/knn-prefiltering/) so filters work *inside* the HNSW traversal, and [continuous KNN performance work](/blog/knn-hnsw-performance/). "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](https://catalog.manticoresearch.com/) with filters, facets, typo tolerance, and semantic search; [reverse image search](https://image.manticoresearch.com/); and [conversational search](https://chat.manticoresearch.com/). ## Relevance: measured, not argued 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. | Mode | Manticore | Meilisearch | |---|---:|---:| | Best mode per dataset (average) | **0.543** | 0.527 | | Vector | **0.530** | 0.527 | | Hybrid | **0.515** | 0.475 | | Full-text | **0.420** | 0.237 | 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](https://www.meilisearch.com/docs/learn/relevancy/ranking_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](https://gist.github.com/manticoresearch/7c9b5d85ca8a62ce0066db6f0e17a11a) 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. ## "Primarily used for complex, large-scale workloads" — the data says otherwise The article claims: > 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](https://manual.manticoresearch.com/Telemetry). Among Manticore instances that report data-size metrics: - **29%** hold less than **1 MB** of data - about **half** hold less than **100 MB** - only about **one in eight** exceeds **10 GB**, and fewer than **1%** exceed **1 TB** 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](/blog/manticore-search-at-scale-on-google-cloud/) after migrating from Elasticsearch. Scaling down and scaling up aren't mutually exclusive. ## Real-time analytics: we'll be honest here too 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](/blog/mcl/), aggregations, [Kibana](/blog/kibana-demo/) and [Grafana](/blog/grafana-dashboard-docker/) integrations, [log-pipeline integrations](/blog/integration-of-manticore-with-logstash-filebeat/) — and it's [well-suited for log search](/blog/kibana-demo/). 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. ## Where Meilisearch's article has a point We promised facts, and facts cut both ways: - **Typo tolerance by default.** True: Meilisearch ships with typo tolerance on. In Manticore, [fuzzy search](/blog/new-fuzzy-search-and-autocomplete/) is opt-in — `min_infix_len='2'` in the table definition and `fuzzy=1` at query time. Two small settings, but Meilisearch's default is the friendlier one. - **Querying straight from the frontend.** Meilisearch's search API keys make backend-less search a first-class pattern. Manticore has traditionally lived behind a backend; [authentication arrived in 27.1.5](/blog/manticore-search-27-1-5/), so that gap is closing, but today the point goes to Meilisearch. - **Documentation gaps.** Every project has them, including us — and including Meilisearch. We'd just push back on "steep learning curve": if you know a bit of SQL *or* a bit of JSON, you know enough to start, and there are [free interactive courses](https://play.manticoresearch.com/) that walk you through everything from first table to vector search. ## Client libraries: the table, completed Since this post is a response to [Meilisearch's comparison](https://www.meilisearch.com/blog/meilisearch-vs-manticore), let's fix its integrations table too. The original lists Go twice with contradictory answers ("supported via community" and "not supported"), gets several official/community statuses wrong — on both sides, in both directions — and skips two languages entirely. Here it is again, checked against [Meilisearch's own SDK docs](https://www.meilisearch.com/docs/learn/resources/sdks) and [Manticore's GitHub org](https://github.com/manticoresoftware): | Integration | Meilisearch | Manticore Search | |---|---|---| | JavaScript (Node.js) | Official client (TypeScript-based) | [Official JavaScript client](https://github.com/manticoresoftware/manticoresearch-javascript) | | TypeScript † | Same official TypeScript client | [Official TypeScript client](https://github.com/manticoresoftware/manticoresearch-typescript) | | Python | Official client (sync + async) | Official [sync](https://github.com/manticoresoftware/manticoresearch-python) and [asyncio](https://github.com/manticoresoftware/manticoresearch-python-asyncio) clients ✱ | | PHP | Official client | [Official PHP client](https://github.com/manticoresoftware/manticoresearch-php) | | Java | Official client | [Official Java client](https://github.com/manticoresoftware/manticoresearch-java) | | Go | Official client ✱ | [Official Go client](https://github.com/manticoresoftware/manticoresearch-go) | | Rust | Community-maintained client ✱ | [Official Rust client](https://github.com/manticoresoftware/manticoresearch-rust) ✱ | | Elixir † | Not listed in Meilisearch's SDK docs | [Official Elixir client](https://github.com/manticoresoftware/manticoresearch-elixir) | | Dart/Flutter | Official client | No official client (HTTP JSON API) | | .NET/C# | Official client ✱ | [Official .NET client](https://github.com/manticoresoftware/manticoresearch-net) | | REST API | Core interface | Full HTTP/JSON API | | SQL | Not supported | Native SQL (MySQL protocol) | † — language missing from the original table • ✱ — status corrected vs the original table (for the Meilisearch column, per Meilisearch's current SDK docs) Adding it up across the ten languages above: **Manticore ships official clients for nine** — everything except Dart/Flutter. **Meilisearch ships official clients for eight** — everything except Rust (community-maintained) and Elixir (not listed). Both cover REST in full, and Manticore additionally speaks SQL over the MySQL protocol. So "a wide range of clients" — the one thing the original article does say about Manticore's integrations — is accurate; the details just needed refreshing. ## The bottom line Meilisearch is a good search engine, and the article gets a real thing right: it's polished for the instant-search, frontend-first use case. If you're choosing for the long haul, though, weigh the cons Meilisearch's own article lists too — for instance, that a search query "must involve no more than ten words; any more will be ignored." Limits like that tend to matter more in month six than on day one. But the bigger issue is that the Manticore the article describes — a complex, SQL-only system for large-scale analytics teams — isn't the Manticore that exists in 2026, and most of it you can disprove in about five minutes of terminal time: ```bash curl https://manticoresearch.com | sh ``` Then insert a JSON document and search it ([more on the one-line installer](/blog/one-line-installer/)). No schema, no config, no "advanced customization." If you want numbers rather than words, the relevance results above, our [benchmark-backed comparison](/blog/manticoresearch-vs-meilisearch/), and [db-benchmarks.com](https://db-benchmarks.com/) are good places to start — and if we got anything wrong about Meilisearch here, we'll happily correct it. That's how we'd want to be treated, too. Questions or disagreements? Come tell us in [the forum](https://forum.manticoresearch.com/) or [Slack](https://slack.manticoresearch.com/).