Scaling Meilisearch: when to shard, when to replicate, when to scale up

Meilisearch is single-node by design. There's no built-in clustering, sharding, or distributed query coordination. Scale by going up (bigger box), not out (more boxes) — until vertical scaling stops working, at which point you start running read replicas behind a load balancer.

The 30-second answer

• Scale up first. Add RAM and faster disk to your existing box. One Meilisearch node handles tens of millions of documents and thousands of QPS on commodity hardware.
• Add read replicas next. When one box can't handle the QPS, run multiple Meilisearch instances with the same data and load-balance reads across them.
• Shard last. When one box can't fit the data, shard at the application layer by index UID or by tenant.

Stage 1: vertical scaling (one node)

Sizing rules of thumb

The headline rule: Meilisearch is RAM-bound. Disk and CPU rarely matter for query latency — RAM matters because the engine memory-maps its index files and benefits hugely from page cache.

Bottleneck signals

• p95 query latency over 200 ms: RAM is too small. The OS page cache is missing for queries that touch cold parts of the index.
• Indexing is slow but querying is fast: CPU-bound during writes. Either reduce write batch sizes or upgrade to a CPU with more cores.
• Disk I/O wait above 20%: Your storage is too slow. Move to SSD or NVMe.

Stage 2: read replicas (load-balanced reads)

The pattern

Run N Meilisearch instances, all with the same index data. Writes go to a single primary; reads are load-balanced across all N. Meilisearch doesn't ship a built-in replication mechanism, so you implement it yourself:

1. Index on the primary. Your application writes only to the primary instance.
2. Snapshot regularly. Use Meilisearch's --schedule-snapshot flag to create snapshots every 5–15 minutes.
3. Sync snapshots to replicas. A small script (cron + rsync) copies new snapshots from the primary to each replica.
4. Replicas reload from snapshots. Each replica restarts with --import-snapshot when a new snapshot lands.
5. Load balance reads. Your application or a reverse proxy (HAProxy, nginx, Envoy) routes search queries across the replica pool.

Eventual consistency tradeoff

Replicas are 5–15 minutes stale. This is fine for most search workloads (the search index is rarely the source of truth) but unacceptable for any workload where users expect to search content the second after they create it. For those, route the offending queries directly to the primary.

Stage 3: sharding by tenant or index

When the index itself outgrows a single box (typically 100M+ documents or 200 GB+ on disk), you can't fix it with a bigger machine. At this point you shard.

Meilisearch doesn't ship sharding either. You do it at the application layer:

Pattern A: shard by tenant

Run one Meilisearch instance per customer (or per group of customers). Your application layer routes queries to the right instance based on the authenticated tenant. This is the cleanest pattern and the easiest to operationalize. AdminDex's instance management workflow is built for exactly this.

Pattern B: shard by index UID

One Meilisearch instance per index UID (or per logical group of indexes). Useful when tenants share schemas but data sizes vary wildly.

Pattern C: shard by hash

Hash documents to N buckets, route writes and reads accordingly, query each bucket and merge at the application layer. This is the most complex pattern and the only one that requires real distributed-systems engineering. Most teams don't get here — and the ones that do are usually better served by a different engine entirely (Elasticsearch / OpenSearch were built for this scale).

When to consider a different engine

If you're hitting scale limits Meilisearch can't solve elegantly, the alternatives are:

• Elasticsearch / OpenSearch for log analytics, multi-petabyte data, complex aggregations. See our Meilisearch vs Elasticsearch comparison.
• Typesense Cluster if you specifically need built-in HA clustering with Raft consensus.
• Algolia or Meilisearch Cloud Enterprise for geographic distribution + SLA, if cost isn't a constraint.

For 99% of teams, single-node Meilisearch on a properly-sized box plus a few read replicas is more than enough.

FAQ

Can Meilisearch run in active-active configuration?

Not natively. Active-active requires distributed write consensus, which Meilisearch doesn't ship. You can fake it with two single-node Meilisearch instances and a load balancer, accepting that writes are eventually consistent.

What about Kubernetes / Docker Swarm with 3 replicas?

Three Meilisearch pods with the same persistent volume mount won't work — Meilisearch holds an exclusive lock on its data directory. Three pods with separate volumes is fine for the read-replica pattern (you sync snapshots between them), but each pod is still independent — there's no consensus.

How big can a single Meilisearch index get?

The hard upper bound is the size of the on-disk LMDB database, which is configured at startup (default 200 GiB). Practically, performance degrades on a single node well before you hit that — most teams shard or replicate before crossing 50M documents.

Does AdminDex help with multi-instance deployments?

Yes — AdminDex is built to manage many instances from one dashboard. Each Meilisearch you operate (primary, replicas, shards) appears as a separate instance with its own settings, keys, tasks, and analytics. This is the right shape for the tenant-sharding pattern in particular.