Fast typo-tolerant search you host yourself, with keys you scope properly.
Meilisearch is a self-hosted search engine that is fast by default and easy to misconfigure in ways that only show up later. It handles typo tolerance, relevance ranking and faceted filtering without tuning, which is most of the appeal.
Reach for it when search is a feature users interact with — an instant results dropdown, a filtered catalogue, documentation search. Reach for your existing database when search is really filtering, because adding a service you have to back up, secure and upgrade is a real cost.
Two decisions have to be made before data is loaded. The first is key design: the master key exists to manage other keys, not to be used by applications. What goes in a browser is a search-only key scoped to a single index with an expiry date. Shipping an admin key to the client is a full read and write of the corpus.
The second is index settings. Searchable, filterable and sortable attributes determine both behaviour and index size, and changing them after documents are loaded reindexes everything. Listing every field as searchable is the common mistake — it dilutes relevance and grows the index for no benefit.
The operational surprises are mild. Writes are asynchronous, so an indexing job that fires updates and exits will report success while the index rejects every one of them; poll the task. And resident memory looks high because the database is memory-mapped, which is page cache rather than allocation — watch search latency instead.
Articles here state the version they were run against, and pin image tags rather
than tracking latest, because the on-disk format has changed between minors.
Start here
A Meilisearch deployment that survives a real workload — master key handling, scoped API keys, the index settings you must set before loading data, snapshots, and what its memory usage actually means.
A reading order that builds Meilisearch knowledge in the sequence it is actually needed.
Failure modes that come up repeatedly with Meilisearch, and where each one is solved.
A Meilisearch deployment that survives a real workload — master key handling, scoped API keys, the index settings you must set before loading data, snapshots, and what its memory usage actually means.
When typo tolerance, relevance ranking and instant faceted filtering are part of the product rather than a convenience. If a `LIKE` query is good enough for your users, adding a service is not an improvement.
Snapshots for fast recovery on the same version — they are a binary copy. Dumps for upgrades and migrations, because they are version-independent but considerably slower to import.
Indexing is the memory-hungry phase, not searching. Roughly 2 GB handles on the order of a hundred thousand modest documents; cap indexing memory explicitly so a large import cannot push the host into swap.