For self-hosted search in 2026, two open-source engines dominate the shortlist once you've ruled out running Elasticsearch yourself: Typesense and Meilisearch. Both ship as a single binary, both give you typo tolerance and search-as-you-type out of the box, and both exist to replace an Algolia bill without the operational weight of a full Lucene cluster. The differences that actually decide things show up once you look at how each one stores data, what it licenses under, and how it behaves when your index grows past the RAM of a single machine.
We pulled both into the same test harness — a product catalog plus a documentation corpus — and indexed, queried, and restarted each one to see where they diverge in practice rather than on a feature grid.
How each one is built
Typesense is written in C++ and holds its entire index in RAM. That single design decision drives everything else. Queries are fast because there's no disk round-trip on the hot path, but your memory budget has to cover the full index plus working overhead. Plan for RAM in the range of your dataset size and then some headroom on top — a catalog that's a few GB on disk wants a comparably provisioned box, not a 1GB instance.
Meilisearch is written in Rust and stores its index in a memory-mapped LMDB key-value store on disk. The OS page cache keeps hot data resident, but the engine doesn't require the whole index to fit in RAM. That makes Meilisearch the more forgiving choice when your corpus is large relative to the hardware you want to pay for, at the cost of disk I/O on cold reads.
Licensing is the other structural fork, and it's easy to ignore until legal asks. Typesense is GPL-3.0. Meilisearch is MIT. If you're embedding the engine or shipping it inside a product where copyleft obligations are a problem, that distinction settles the question before any benchmark does.
Two things catch teams late. Typesense's all-in-RAM model means an index that grows faster than you expected can push the process toward an out-of-memory kill, so size for headroom and watch memory as a first-class metric. And Typesense's GPL-3.0 license can conflict with proprietary distribution in a way Meilisearch's MIT license never will — confirm with whoever owns licensing before you build on it, not after.
Search features and developer experience
Feature parity is much closer than it was two years ago. Both engines now handle:
- Typo tolerance with configurable edit distance
- Faceting, filtering, and sorting
- Vector and hybrid (keyword plus semantic) search
- Geo search
- Synonyms and stop words
Where they differ is in texture. Meilisearch leans into good defaults. You point it at JSON, it infers field types, and relevance is tuned to feel right for the common case with minimal configuration. Its ranking rules are a readable, reorderable list — words, typo, proximity, attribute, sort, exactness — which makes relevance debugging legible instead of opaque. For a team that wants search working on day one without a dedicated relevance engineer, that's the pitch.
Typesense gives you more explicit control and surfaces more knobs. The schema is typed and declared up front rather than inferred, which catches data problems at index time instead of surfacing them as bad results at query time. It also ships capabilities Meilisearch doesn't match one-for-one: federated multi-search across collections in a single request, curation and overrides for pinning specific results, and finer control over vector search parameters. If you're building something closer to a search platform than a search box, that extra surface area earns its keep.
On the API side, both are pleasant to work with. REST-first, official client libraries for the languages you'd expect, and Docker images that run with a single command. InstantSearch adapters exist for both, so Algolia-style front-end widgets work either way and your front-end code barely cares which engine sits behind it.
Which one should you pick
The honest answer: for a mid-sized catalog or docs search, either will serve you well, and you'll spend more hours on your schema and ranking than on the engine choice itself. But the tie-breakers are real.
Pick Meilisearch if your index might outgrow a single machine's RAM, you want relevance that's good without manual tuning, MIT licensing matters to how you distribute, or you simply value the smaller-configuration path to a working search box.
Pick Typesense if you want every query served from memory with predictable low latency, you need federated search or result curation, you prefer an explicit typed schema that fails loudly on bad data, and GPL-3.0 is fine for your deployment model.
Both offer a managed cloud — Typesense Cloud and Meilisearch Cloud — if you'd rather not run and patch the binary yourself. That's worth pricing against the engineering time self-hosting actually costs once you account for backups, upgrades, and on-call. The break-even point arrives sooner than most teams assume.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)