Meilisearch Review: The Thing That Breaks at 5,000 Listings

Your directory's search box works fine. You have 300 listings and a database query behind a text field, and it returns what people ask for.

Then you import a scrape and you have 5,000 listings, and three things happen at once.

The query gets slow, because a LIKE '%coffee%' scan across five thousand rows is a full table scan and no index saves you. Someone types "cofee" and gets nothing. And someone types "italian restaurant brooklyn" and gets nothing, because no single field contains that string.

That is not a bug you fix. It is the point at which a database filter stops being a search feature, and you need an actual search engine.

What Meilisearch is

A search engine you put in front of your data. You send it your listings, it builds an index, and your front end queries the index instead of the database.

The headline claim is sub-50-millisecond responses. In practice that means the results update as the person types, which changes the interaction entirely. Search-as-you-type is not a garnish on a directory, it is how people expect to browse a list of things.

Typo tolerance is on by default. "Resturant" finds restaurants. Nobody has to configure a synonym list for that, which matters because you will not maintain a synonym list.

It handles faceted filtering, which is the directory pattern exactly: search "plumber", then filter by city, then by rating, then by whether they do emergency callouts. Facets also return counts, so you can show "Brooklyn (47)" beside the filter rather than letting someone click into an empty result set.

Ranking is configurable, so you can decide that a paid listing outranks a free one at equal relevance. That is a monetisation feature disguised as a search setting.

Why this is not premature optimisation

The instinct is to leave search until later, and for most infrastructure that instinct is right.

It is wrong here, for a specific reason. Search is the primary interaction on a directory. A visitor lands on a category page, types what they want, and either finds it or leaves. There is no second chance and no other path through the site that rescues a bad result.

So the quality of your search is not a nice-to-have layered on top of your listings. It is most of what your visitors experience of your listings.

The good news is that adding Meilisearch later is not a rebuild. It sits alongside your existing database rather than replacing it. You keep your data where it is, push it into an index, and point the search box at the index.

Pricing

The cloud trial is 14 days with no credit card.

That worked example is the useful number. A hundred thousand listings and fifty thousand searches a month is a directory that is genuinely working, and it costs about $30. Usage-based pricing means a directory nobody has found yet costs almost nothing, which is the right shape for something you are still validating.

Self-hosting is free and Meilisearch is a single binary, which is unusually painless as infrastructure goes. If you already run a VPS for your database, this goes on the same box.

The licence, precisely

The core is MIT. Permissive, commercial use fine, no obligations worth worrying about.

The Enterprise Edition is Business Source License 1.1, which is not an open-source licence. BSL restricts production use in certain competing scenarios for a period, after which it converts to an open licence.

For running a directory this is irrelevant, because the MIT core is the part you use. It becomes relevant only if you intend to offer search-as-a-service built on Meilisearch, at which point read the BSL terms rather than assuming.

Worth stating clearly, because "open source with a BSL edition" gets flattened to "open source" in a lot of write-ups, and the two things are not the same.

Where it fits in a directory stack

In front of your listings database. NocoDB, Baserow, Postgres, whatever holds the rows. Meilisearch indexes them and answers queries. The database stays the source of truth.

Powering the filter UI. Facets with counts are what make a large directory browsable rather than merely searchable. This is where a directory stops feeling like a spreadsheet with a search box.

Ranking paid placement honestly. Custom ranking rules let a featured listing sort above an equally relevant free one. That is a defensible way to sell placement, because relevance still comes first and you are only breaking ties.

Where it does not fit

Below about a thousand listings you probably do not need it. A database query over a small table is fast enough and simpler. Adding a search engine to a 200-item curated list is work you did not have to do.

It is another moving piece. Self-hosted, that is another service to run, monitor and back up. Cloud, that is another bill and another dependency.

Your index has to stay in sync. When a listing changes in the database, something has to update the index. That is a small automation, and it is a real one that you have to build and then remember exists.

And it is not a database. Meilisearch searches; it does not store your authoritative data. Do not put your only copy of anything in it.

Common questions

How does it compare to Algolia?

Algolia is the incumbent and is excellent. It is also considerably more expensive at directory scale and cannot be self-hosted. Meilisearch is the answer when Algolia's bill is the problem or when self-hosting matters to you.

Do I need to be a developer?

To wire it in, yes, somewhat. It is a REST API with official client libraries, so it is not exotic, but it is not point-and-click either. If your directory is on a no-code platform, check whether that platform can talk to an external search API before planning around this.

How do I get my listings into it?

Push them as JSON through the API, either in bulk for the initial index or one at a time on change. If you already run n8n, a workflow that watches your database and updates the index is a straightforward build.

Does it work for non-English content?

Yes, with multi-language support built in. Relevant if your directory covers a non-English market or mixes languages.

Is 50ms actually noticeable?

Yes, because it is the difference between search-as-you-type feeling instant and feeling laggy. Under about 100ms reads as immediate to a person. A database scan at scale does not get near that.

Verdict

Meilisearch is the piece most directory builders add too late, after search has already been the reason people bounced.

The argument for adding it earlier is not performance for its own sake. It is that search is the product on a directory, and a database filter is not search. Typo tolerance alone recovers a meaningful share of queries that would otherwise return nothing.

If you are under a thousand listings, note this and move on. If you are past it, or your scrape is about to put you past it, run the 14-day trial with your real data and type a misspelling into it. That is the test.