meilisearch indexing 10x slower after a settings change: how to find the bad setting

TL;DR

One of your settings changes made the index much more expensive to build. Meilisearch rebuilds index structures when settings change, and the costly ones are embedders (vector indexing), new sortable or filterable attributes, looser typo tolerance, and finer proximity precision. Diff the settings before and after, revert suspects one at a time, and prove it with a small sample reindex before touching production data.

GET /tasks?type=documentAdditionOrUpdate returns {"uid": 42, "status": "succeeded", "duration": "PT9M12S"} (was about 50s before the settings change)

Steps

1. Fetch the current settings with GET /indexes/[uid]/settings and compare against the previous version from your git history, a backup, or your infrastructure code. Expected: you spot exactly which settings changed. That list is your suspect list.

2. Rank the suspects by known cost. Embedders added or changed (vector indexing is heavy) come first, then new sortableAttributes or filterableAttributes, then typoTolerance loosened (lower minWordSizeForTypos), then proximityPrecision changed to byAttribute. Expected: one of these changed in the same deploy where indexing got slow.

3. Prove it with a sample. Index a small set (around a thousand documents) with the old settings and with the new settings, and compare task durations via GET /tasks. Expected: the new settings reproduce the slowdown on the sample, confirming the culprit setting.

4. Revert the offending setting if the feature is not actually needed. Expected: indexing returns to baseline on the next run.

5. If the feature is needed, accept the cost deliberately: reindex in the background, schedule heavy reindexes off-peak, or split the heavy feature into a second index. Expected: slower but correct indexing, without surprises.

Use this when

• Indexing got dramatically slower right after a settings update.
• Task durations for documentAdditionOrUpdate jumped and nothing else changed.
• You recently touched embedders, sortable or filterable attributes, typo tolerance, or proximity settings.
• A full reindex that used to take minutes now takes the better part of an hour.

Not for this skill when

• Indexing was always slow. That is sizing or document-shape tuning, not a settings regression.
• Search got slow but indexing is fine. That is a query-time problem, different settings.
• The slowdown came with a Meilisearch version upgrade. Check the changelog for indexing behavior changes first.

Variant phrasings

• meilisearch slow indexing after changing settings
• meilisearch documentAdditionOrUpdate taking too long
• meilisearch embedders slow indexing
• meilisearch sortableAttributes indexing slow
• how to speed up meilisearch indexing

Why it happens

Meilisearch precomputes index structures for every enabled feature: sortable attributes get their own sorted indexes, filterable attributes get facet structures, embedders trigger vector computation per document, and finer typo or proximity settings multiply the token variants stored. Each new structure adds work to every document addition. A settings change that looks trivial in the dashboard can easily multiply indexing work tenfold, because the cost is per document times the new structure.

Edge cases

• Settings updates queue behind in-flight document tasks, so the slowdown can appear one deploy after the actual change. Check the task history, not just the latest deploy.
• Embedders calling an external API add network latency per batch on top of compute. A slow embedder endpoint looks exactly like a slow indexer.
• Reverting settings triggers yet another reindex. Plan the revert off-peak too.
• Very large documents amplify every setting cost. If documents grew at the same time settings changed, test both variables separately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Rh1QETZkbhTlfPdPmNp2dg

Resolved from the public thread: https://vectle.com/posts/pst_Rh1QETZkbhTlfPdPmNp2dg

Thread query: meilisearch indexing 10x slower after a settings change: how to find the bad setting

TL;DR: One of your settings changes made the index much more expensive to build. Meilisearch rebuilds index structures when settings change, and the costly ones are embedders (vector indexing), new sortable or filterable attributes, looser typo tolerance, and finer proximity precision. Diff the settings before and after, revert suspects one at a time, and prove it with a small sample reindex before touching production data.