<!-- llms-explorer concept facts · https://llms-explorer.com/tree/mixed-schema-measurement-predicate-safety/ · pack 2026-10-31 · ~1691 tokens -->

# Mixed-schema measurement predicate safety

> Source-anchored research for Mixed-schema measurement predicate safety. Run status: COMPLETED.

Parent: [Bucket-level predicate rewriting for measurement operators](https://llms-explorer.com/tree/bucket-level-predicate-rewriting-for-measurement-operators/) · 4 facets · 17 facts · page: https://llms-explorer.com/tree/mixed-schema-measurement-predicate-safety/

## Structure and components

- Time-series measurement pushdown must preserve every bucket that could contain a match. MongoDB's query README describes control.min/control.max bucket filters before unpacking; SERVER-59505 demonstrates why naïvely applying these bounds to mixed arrays/scalars or objects/non-objects can wrongly discard matching measurements. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/timeseries/README.md)

## How it works

- SERVER-59505 reproduces x:[0,2], x:[3,1], and x:10 in one bucket whose control.min.x is 10: an unsafe pushed-down x<5 test excludes the bucket even though array elements match. It also shows that control.max.x.y need not be the maximum of x.y when x mixes objects and non-objects. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-59505)
- The old-collection explanation is not exhaustive: SERVER-107361 records that keeping buckets open for large measurements could skip schema checks even when timeseriesBucketsMayHaveMixedSchemaData was false. Percona's release notes repeat this upstream defect and its upgrade-plus-collMod remediation. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-107361)

## Problems, failure modes and limitations

- Methodological inference: an empty result caused by unsafe bucket pruning cannot be repaired merely by choosing a faster access path. Investigate correctness separately before attributing observed behavior to replanning; these bug records do not establish a replanReason signature. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-59505)
- In the master MixedSchemaBucketsState header read on 2026-10-30, mustConsiderMixedSchemaBucketsInReads returns true for every state except NoMixedSchemaBuckets, explicitly including Invalid to fail safe. canStoreMixedSchemaBucketsSafely returns true only for DurableMayHaveMixedSchemaBuckets. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/timeseries/mixed_schema_buckets_state.h)
- A firsthand September 2022 report describes a measurement-field index build failing on MongoDB 6.0.1 with a mixed-schema bucket error while metadata/time-field indexes succeeded. This is a historical user observation, not evidence that measurement indexes are generally unsupported in 6.0+. (low confidence) — [source](https://stackoverflow.com/questions/73855411/mongodb-time-series-add-secondary-indexes)

## Facts and statements

- MongoDB's time-series query implementation describes measurement equality filtering with control.max >= value and control.min <= value before unpacking. This is bucket pruning; mixed-type correctness requires additional care beyond the simplified bounds example. (medium confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/timeseries/README.md)
- SERVER-59505 lists fixes in 5.0.4, 5.1.0-rc3, and 5.2.0. Its reproducer describes a historical defect and must not be presented as proof that all current mixed-schema queries return incorrect results. (low confidence) (verified as of 2024-12-12) — [source](https://jira.mongodb.org/browse/SERVER-59505)
- SERVER-91194 documents that cloning collections created in 5.0–5.1 could lose timeseriesBucketsMayHaveMixedSchemaData, making queries miss matches. TOOLS-3777 explains why a true catalog flag can remain unsafe if its durable WiredTiger configuration representation is absent. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-91194)
- For collections affected by SERVER-91194, the documented remediation combines upgrading to a fixed version with setting timeseriesBucketsMayHaveMixedSchemaData:true using collMod. An upgrade alone does not prove historical collection metadata is repaired. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-91194)
- SERVER-107361 lists fixed versions 7.0.26 and 8.0.13, alongside 8.2.0-rc3 and 8.3.0-rc0. Percona documents inclusion of the fix in its 7.0.26-14 release; this is downstream confirmation of an upstream fix, not an independent discovery. (medium confidence) (verified as of 2025-11-25) — [source](https://jira.mongodb.org/browse/SERVER-107361)
- MongoDB records SERVER-59505 as fixed in 5.0.4, 5.1.0-rc3 and 5.2.0. These historical fix versions do not establish that every later mixed-schema defect is fixed. (low confidence) (verified as of 2024-12-12) — [source](https://jira.mongodb.org/browse/SERVER-59505)
- SERVER-91194 concerns collections created in 5.0–5.1 and subsequently cloned after upgrade: initial sync, chunk migration, movePrimary, resharding and dump/restore could default timeseriesBucketsMayHaveMixedSchemaData to false. Missing flag information can make reads omit matching documents that remain stored. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-91194)
- validate can detect mixed-schema buckets inconsistent with the catalog flag. SERVER-91194 warns that validation can be impactful and recommends its linked hidden-secondary procedure to reduce production impact. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-91194)
- SERVER-107361 shows that large-measurement bucket rollover could return kNone before checking schema incompatibility, permitting mixed-schema data despite a false catalog flag. This scopes any blanket claim that post-5.2 bucket creation always prevents mixed schemas. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-107361)
- SERVER-107361 lists fixes in MongoDB 7.0.26, 8.0.13, 8.2.0-rc3 and 8.3.0-rc0. Percona's 7.0.26-14 and 8.0.16-5 notes include the fix and repeat the requirement to flag affected collections after upgrading; these release notes describe incorporated upstream fixes, not independent discovery. (high confidence) (verified as of 2026-09-29) — [source](https://jira.mongodb.org/browse/SERVER-107361)
- For investigation of replanning loops, treat mixed-schema predicate safety as a separate correctness prerequisite: the cited defects concern unsafe bucket pruning or lost catalog state. They do not establish that a replanReason message identifies or repairs mixed-schema buckets; this is a diagnostic inference from the defect mechanisms. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-59505)
