Collation-based case-insensitive equality
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-24
↓ Facts as markdownall context files
Source-anchored research for Collation-based case-insensitive equality. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- A case-insensitive regex is not a substitute for collated equality when the requirement is whole-string equality. MongoDB's regex operator is not collation-aware, and a case-insensitive index does not provide the intended regex optimization. (high confidence) [source]
Problems, failure modes and limitations
- An operation's effective collation must match the index collation for indexed string comparisons. Two collations can both ignore case yet remain incompatible: the manual's strength-1 query cannot use its strength-2 string index. (high confidence) [source]
- One collation applies to the entire operation. A find with sort cannot choose separate collations for filtering and sorting, and individual fields cannot receive different collations within that operation. (high confidence) [source]
Facts and statements
- For whole-string case-insensitive equality, create an index such as {name:1} with collation {locale:'en',strength:2}, and issue find({name:'Alice'}).collation({locale:'en',strength:2}). Matching collation makes that index eligible for the string comparison. (high confidence) [source]
- Queries and indexes inherit the collection's default collation unless they explicitly override it. An index-level collation does not become the query default; on a collection without that default, the query must specify the matching collation. (high confidence) [source]
- With caseLevel:false, strength:1 compares base characters and ignores case and diacritics; strength:2 also distinguishes secondary differences such as diacritics. Setting caseLevel:true reintroduces case comparisons at either strength, so strength alone does not fully specify case-insensitive behavior. (low confidence) [source]
- In an April 2, 2020 Parse Server incident report, adding case-insensitive indexes coincided with regex queries selecting them and running approximately four times slower; the reporter said hinting the existing case-sensitive index restored prior timings. This is historical workload evidence, not a current universal slowdown factor. (low confidence) [source]
- Spring Data warns that MongoDB's automatic collection creation on first interaction does not apply an entity's annotated collation. Applications relying on that collection default should create the collection explicitly through MongoOperations.createCollection. (low confidence) [source]
- Collation-aware indexes store ICU collation keys, which can be larger than keys in indexes without collation. Index eligibility therefore does not imply identical index storage costs. (low confidence) [source]
- An equality predicate can match case variants using collation; MongoDB demonstrates {type: "apple"} with {locale: "en", strength: 2} matching apple, Apple, and APPLE. (medium confidence) [source]
- With caseLevel disabled, strength 2 ignores case while retaining secondary differences such as accents; strength 1 ignores secondary differences too. Locale tailoring can classify some accented letters as primary differences. (medium confidence) [source]
- Setting caseLevel: true restores case distinctions at strengths 1 and 2; specifying a low strength alone therefore does not guarantee case-insensitive equality. (medium confidence) [source]
Children
- No children recorded.