Should synonym expansion in Elasticsearch run at index time or at search time, and why?

## The same result set, very different operations Synonym expansion can be placed on either side of the analysis boundary, and for simple one-word-to-one-word rules both placements can produce the same hits. Doing it at index time means the document `"laptop"` also stores the term `notebook`, so a plain query for `notebook` finds it. Doing it at search time means the document stores only `laptop`, and the query `notebook` is expanded to `notebook OR laptop` before lookup. The retrieval outcome looks alike; the engineering consequences do not. ## Index time: cheap queries, expensive change What index-time expansion buys is per-query simplicity — no filter runs on the query, and the query stays a single term lookup. What it costs: - **Reindexing on every rule change.** Synonyms are exactly the kind of configuration a search team iterates on weekly. Baking them into segments means each iteration is a full reindex of the corpus. - **Distorted term statistics.** BM25 scores a term partly by its inverse document frequency. Injecting synonyms raises the document frequency of the injected terms and changes the field length used for length normalization, so relevance shifts in ways unrelated to the actual content. - **Broken provenance.** Highlighting and debugging show terms that never appeared in the source text, and there is no way to tell an expanded term from a real one. - **Multi-word trouble.** Rules like `ny, new york` must map one token to two, or two to one. At index time this forces awkward position handling, and the graph-aware `synonym_graph` filter is not available for index analyzers at all — it is documented as a search-analyzer filter, precisely because a graph token stream is something a query parser can consume but an index cannot store faithfully. ## Search time: the default choice Search-time expansion keeps the inverted index a faithful representation of the source text. That single property gives you most of the advantages: term statistics stay honest, highlighting shows real terms, and reindexing is decoupled from relevance work. It also unlocks the correct machinery for multi-word rules. `synonym_graph` emits a token graph — alternative paths through the query, so `"ny pizza"` can be understood as either `ny pizza` or `new york pizza` — and full-text queries know how to turn that graph into the right boolean or phrase structure. That is far more accurate than anything achievable by stuffing extra tokens into the index. Operationally, a search-time synonym filter can be declared `updateable: true` (allowed only when the analyzer is used purely as a search analyzer). The rules then live in a file on every node, and `POST /<index>/_reload_search_analyzers` picks up an edited file on a live index — a rule change goes out in seconds without touching data. Recent 8.x versions additionally offer a managed synonyms API for storing synonym sets in the cluster rather than in files on disk; either way the point stands that the search side is the changeable side. The cost side is real but modest: each query runs the filter and expands into more term lookups, so a rule set that expands one word into ten multiplies the clause count. Very large rule sets, or rules that chain into each other, can make queries measurably slower and can also flatten relevance because a rare word and its common synonym have very different IDFs — a document matching only the common synonym may score surprisingly high or low. ## Choosing Default to search time. Choose index time only when all of the following hold: the vocabulary is genuinely frozen (standardized product codes, unit abbreviations), query latency is at a premium, and the rules are one-word-to-one-word so the position problem never arises. Even then, document the decision loudly, because the next person who wants to change a synonym will otherwise discover the reindex requirement the hard way. A hybrid also exists and is sometimes the pragmatic answer: normalize a small, stable set of equivalences at index time (unit spellings, brand casing) and keep the evolving, business-driven vocabulary in the search analyzer. ## What interviewers listen for The strong answer is not "search time" on its own — it is the pairing of reasons: mutability without reindex, honest term statistics, and graph handling of multi-word rules, against the honest admission that you pay for expansion on every query and that IDF differences between a term and its synonym still make scoring imperfect on either side.