Meilisearch

What Meilisearch is

Meilisearch (github.com/meilisearch/meilisearch) is a search engine written in Rust by Meili SAS, a company based in France. You run the binary, push JSON documents into an index, and query it over HTTP; there are official client libraries for most languages. The project started in April 2018 and is under continuous development — releases ran from v1.52.0 on 3 August 2026 to v1.53.1 on 13 August 2026, the default branch takes functional commits most days, and there were 315 open issues at capture.

• Typo tolerance and search-as-you-type are the defaults You do not tune a relevance pipeline to get a usable box. The project's stated target is results in under 50 milliseconds, and a misspelt query still matches.
• Hybrid search runs in one query Keyword matching and vector search are combined, so a phrase that shares no words with your documents can still match on meaning. You supply the embedder.
• Filters, facets, sorting and geo come with it These are the parts that turn a search box into a browse interface — the difference between looking something up and letting people explore a catalogue.
• Multi-tenancy is handled by tenant tokens Scoped keys restrict what a given user can see, which is how search goes inside a product that serves many customers without maintaining an index per customer.
• Language support is stated explicitly, and that matters The project names optimised handling for Chinese, Japanese, Hebrew and languages using the Latin alphabet. Check your own languages against that list rather than assuming.
• It plugs into AI stacks There is a LangChain integration and a Model Context Protocol server, if you want an agent querying your index rather than a person.

The licence line, and where it falls

This one is worth reading before you commit, because the repository is not simply MIT. Its LICENSE file declares `SPDX-License-Identifier: MIT AND BUSL-1.1`: the Community Edition is MIT and free for commercial use, while an Enterprise Edition — sharding and S3-streaming snapshots — sits under the Business Source License 1.1, which the project states is not permitted in production without a commercial agreement. That is an open core split, and the useful detail is where the line falls. A single node is entirely MIT. You reach the commercial boundary when you outgrow one machine, which for most early products is a long way off.

Two smaller things to decide at install rather than later. There is a hosted option, Meilisearch Cloud, and it is not only hosting — the project lists analytics and monitoring among the extras it adds, which is relevant to the next section. And the self-hosted binary collects anonymised telemetry by default; the documentation explains how to switch it off, so make that a deliberate choice while you are still in the config file.

The growth argument is the query log, not the search box

Site search is the only place on your website where visitors tell you, unprompted and in their own words, what they expected to find. There is no incentive to be polite as there is in a survey, and unlike keyword research the volume is small but the intent is undeniable: these are people already on your site, already interested, typing what they wanted.

Meilisearch answers the query. In the self-hosted build it does not hand you a dashboard of what was asked — analytics is listed among the Cloud extras — so the capture is yours to wire. That is an afternoon of work and it is where the whole payoff lives. Do it in this order.

1. Log every query with its result count The string typed, how many results came back, and which page it was typed on. Two columns and a timestamp is enough to start; you can always enrich later.
2. Read the zero-result queries first This is the highest-value line in the entire log. Somebody wanted something specific enough to type it and you returned nothing. Some are misspellings the engine should have absorbed, some are features you do not have, and some are things you do have under a name nobody uses.
3. Sort the rest by frequency and read the top twenty out loud The words your customers use are usually not the words on your homepage. That gap is free positioning research, and it costs nothing but the reading.
4. Fix the vocabulary before you fix the product Synonyms are a configuration change. If people search for "invoice" and your product says "billing", teach the index both before you conclude anything about demand.
5. Feed what is left into content and keyword work A query typed by somebody already on your site is a stronger statement of search intent than a volume estimate from a keyword tool — see keyword research for a startup.

One warning from our own experience, because this is the failure that hides. We publish in eight languages. We once audited our own copy for a word we had banned from customer-facing text, using a word-boundary search, and it came back clean — while 149 real instances sat in the files. The pattern could not match Chinese, Japanese or Korean text, which does not separate words with spaces, so the check reported silence and we read the silence as health. Search has exactly that shape: if your index splits on whitespace, a Japanese visitor's query returns nothing, and your log reads as "nobody searches in Japanese" rather than "search is broken in Japanese". Meilisearch names optimised handling for a specific set of languages; if you sell in a script outside it, type a real query in that script yourself before you trust the log.

Where it fits, and when it does not

Search stops being a nicety somewhere around the point where your navigation no longer fits on one screen. A docs set, a blog archive, a product catalogue or a directory all cross that line faster than founders expect. Our own marketing site is well past it — roughly 450 pages across eight languages at the time of writing — which is the kind of corpus where a visitor is better served by typing than by hunting through a menu.

Be honest about the limit, though: search quality is a content problem wearing an infrastructure costume. A fast engine over thin, badly titled documents returns fast, bad results, and no amount of tuning rescues that. Running it yourself is also an operational commitment — a process, a disk, backups, upgrades. For many small sites the search built into your CMS or a hosted service is the right answer, and Meilisearch earns its place when you want control over relevance, need it inside your own application, or care where the data lives. If you are choosing the layer underneath first, PocketBase covers the app backend and docmd the documentation side.

The sequencing we would suggest: ship search because visitors need it, capture the queries from day one because they cost nothing to store and cannot be recovered retrospectively, and read them monthly as customer research rather than as a performance metric. Turning what you learn there into pages, positioning and outbound is the slower half — that is where AgentCeres — the AI Growth Officer, at agentceres.com — drafts alongside you, with a person approving anything that goes out.