Meilisearch vs Typesense

Meilisearch and Typesense are the two open-source engines people usually weigh when they want Algolia-style search without Algolia's bill. Typesense's README calls itself "an Open Source Algolia Alternative". Both do search-as-you-type with typo tolerance, filters and facets, geo search and hybrid keyword-plus-vector search, and both ship as a single binary behind a REST API. The real differences are underneath: where the index lives, what high availability costs you, and which licence you get. Those three decide the choice more than any feature list.

Where the index lives: disk vs. RAM

This is the difference that sizes your server.

Meilisearch stores its data in LMDB, a memory-mapped key-value store. Its storage docs say it "works optimally when the full dataset fits in RAM", but that "a RAM-to-disk ratio around 1/3 does not materially impact performance", that for many workloads about 1/10 works, and that Meilisearch "will not crash simply because the dataset size on disk exceeds the available RAM." The OS decides how much of the map stays in memory. Indexing is the hungry part: the indexer caps itself at two thirds of the machine's RAM by default (--max-indexing-memory changes that), and most out-of-memory kills happen while indexing. On a low-latency disk the rest is page cache. Upstream's own example is a roughly 9 MB JSON dataset of 19,553 movies, which took 224 MB on disk and about 305 MB of RAM. The disk file also only grows: deleted documents free space inside LMDB but not back to the OS.

Typesense is, in its own words, "an in-memory datastore": it keeps "the entire search index in-memory and a copy of the raw data on disk." Its system requirements page is refreshingly concrete. The idle process takes about 20 MB. For keyword search, plan on 2–3× the size of the fields you actually search on, so 1 GB of searchable field values means 2–3 GB of RAM. Fields you only display can be left out of the schema and stay on disk. Vectors cost 7 bytes per dimension per record, and the built-in embedding models need another 2–6 GB of RAM on top. Typesense also states that it "requires at least 2 vCPUs." The upstream production guide says to keep RAM use under 85% and to treat any swap use as a sign you need more memory. After a restart, Typesense rebuilds the in-memory index from the data directory.

Neither project publishes a flat minimum, so the 1 GB floor we list for each is our own estimate for a small index, not an upstream figure and not a measurement. The practical rule: if your searchable data is small and bounded, the RAM model barely matters. If it grows without a ceiling, Meilisearch's disk model is the cheaper one to run on a single VPS.

High availability and licensing

Here the trade flips.

Typesense includes clustering in its GPL-3.0 build. It uses Raft, you need "a minimum of 3 nodes" to survive one failure (five survive two), and every node holds a full copy of the data. Reads are served by whichever node receives them; writes are forwarded to the leader. The same design means Typesense does not shard: each node needs RAM for the whole index.

Meilisearch has a split licence. The repository is MIT AND BUSL-1.1: the Community Edition, which is what the getmeili/meilisearch image builds, is MIT. Code in the enterprise_edition modules is under a Business Source Licence that allows "non-production purposes only", so production use needs a commercial agreement. Its docs name sharding as the only Enterprise-only feature. The replication-and-sharding guide also says both "require the Meilisearch Enterprise Edition", and the Enterprise builds ship as separate meilisearch-enterprise binaries and images. So a free, self-hosted Meilisearch is a single node. You get redundancy from snapshots and a restore, not from a live replica.

On the licences themselves: MIT asks nothing of you. GPL-3.0 only applies when you distribute a modified Typesense. Running it as a separate service, even behind a commercial product, triggers nothing, and Typesense's README explains that it chose GPL instead of AGPL for exactly that reason. Its client libraries are Apache-licensed.

Search features

The overlap is large, so the details matter more than the checklists.

• Typo tolerance is on by default in both. Meilisearch allows one typo from 5 characters and two from 9. Typesense allows up to two by default (num_typos), with one from 4 characters and two from 7. By default it only looks for typo variants when a search finds no exact results (typo_tokens_threshold).
• Filters, facets and geo. Both do faceted filtering and geo search by radius, bounding box and polygon.
• Vector and hybrid search. Both take your own embeddings or generate them. Meilisearch embedders include OpenAI, a generic REST source, and a HuggingFace source that runs open models on your own server. Typesense has built-in models such as S-BERT and E-5 plus OpenAI and other APIs. Both also have a conversational, RAG-style search endpoint.
• Multi-tenancy. Meilisearch issues tenant tokens: short-lived JWTs, signed with an API key, that embed filters applied to every search. Typesense issues scoped search keys with an embedded filter_by, generated in your backend. Either way, one index can serve many customers safely.
• Tuning style. Typesense sets field weights, grouping and much of the ranking at query time. Meilisearch ranks fields by the order of its searchable-attributes setting and ranking rules on the index.

Running it

Both are one container and one data directory. Meilisearch needs MEILI_ENV=production and a master key of at least 16 bytes. Without that, it runs in development mode with a search-preview UI. It generates default search and admin API keys from the master key, and it sends telemetry unless you set MEILI_NO_ANALYTICS. Typesense starts with a bootstrap admin key (--api-key), and its docs "strongly recommend" creating scoped keys and never putting that one in an application. It can serve HTTPS itself (--ssl-certificate).

Backups and upgrades differ. Meilisearch databases are tied to the version that created them. Upgrades use --upgrade-db, which upstream warns is "not atomic", so take a snapshot first. Databases from before v1.12 need a dump and re-import. Typesense backups go through its snapshot API. Upgrades are a binary or image swap and a restart, done as a rolling upgrade on a cluster (followers first, leader last). Both engines pin cleanly to a version tag. Meilisearch advises against :latest. We rate both 2 out of 5: easy to run, but each is an API your application has to integrate, not a finished search page.

Which to choose

Choose Meilisearch for a single server where the data may outgrow RAM, where you want an MIT licence, or where language handling matters. Upstream highlights optimised tokenisation for Chinese, Japanese, Hebrew and Thai. It is also already running inside some self-hosted apps, such as Karakeep, which bundles it as the full-text index. Choose Typesense if you need high availability without an enterprise contract. Its Raft cluster is in the free build. It also suits you if your searchable data fits comfortably in memory and you want query-time control over ranking. Neither wins outright. Your data size and your uptime requirement decide it.

Choosing between Typesense and Meilisearch

Put the other way round: start with Typesense when a dropped search node is a real outage for you and you can budget RAM for the whole index on three machines. Start with Meilisearch when one well-backed-up box is acceptable and you would rather size for disk than for memory.