What can a MongoDB text index do, and what restriction applies per collection?

## What it is A text index is a special index type declared by putting the string `"text"` where a direction would go: ``` db.articles.createIndex({ title: "text", body: "text" }) ``` Instead of storing field values, it stores **terms**: each indexed string field is split into words, stop words for the configured language are removed, and each remaining word is reduced to a stem. The resulting terms are what the index holds, so the index is a mapping from word-stems to documents. ## How you query it The query operator is `$text` with a `$search` string: ``` db.articles.find({ $text: { $search: "mongo indexing" } }) ``` Space-separated terms are ORed by default; a phrase in double quotes must appear as a phrase; a term prefixed with `-` is excluded. Matching is case-insensitive and diacritic-insensitive, and it is stem-based, so `running`, `runs` and `ran`-style variants collapse to a common root depending on the language rules. ## The one-per-collection rule A collection may have **at most one** text index. It may span many fields, but you cannot have two separate text indexes on two different field sets. In practice that means adding a searchable field is a drop-and-recreate operation on the single text index, and it makes the text index a shared, collection-wide resource rather than something each query pattern gets its own copy of. Two related options matter when the one index has to serve everything: - **`weights`** — per-field multipliers that make matches in some fields count more towards relevance than others, for example title over body. - **`default_language`** — chooses the stemming and stop-word rules; a per-document language override field is also supported. - **`{ "$**": "text" }`** — a wildcard text index over every string field in every document. Convenient, and correspondingly expensive to build and maintain. ## Relevance scoring Text matches carry a relevance score, but it is not part of the result unless you ask for it. You project it and sort by it with the `$meta` expression: ``` db.articles.find( { $text: { $search: "indexing" } }, { score: { $meta: "textScore" } } ).sort({ score: { $meta: "textScore" } }) ``` Sorting by an ordinary field instead is legal and simply ignores relevance. ## What it deliberately does not do This is where candidates most often over-claim: - **No substring or infix matching.** The index holds whole word-stems, so searching for a fragment inside a word finds nothing. It is not a `LIKE '%x%'` replacement. - **No prefix/autocomplete matching** out of the box. - **One `$text` expression per query.** You cannot combine two independent text searches in a single filter. - **In an aggregation pipeline, `$text` must appear in a `$match` at the start of the pipeline**, not after arbitrary stages. - **Compound restrictions.** A compound index that includes a text key can carry ordinary equality-prefix keys alongside it, but it cannot combine a text key with other special index types such as geospatial keys. ## When it is the right tool A text index is the built-in, self-managed option for word matching within a collection: good enough for filtering on keywords, tagging, and simple search boxes over modest corpora. Once the requirements grow into analyzers, faceting, fuzzy matching or ranked multi-field relevance tuning, teams generally move that workload to a dedicated search product rather than pushing the text index further. ## Answering well Name the declaration syntax and the `$text` operator, state the one-index-per-collection rule plainly, then volunteer the limitation that matters in practice — word-based, no substring matching — and mention `$meta: "textScore"` for relevance. That combination shows you have actually used it rather than read the feature list.