<!-- llms-explorer concept facts · https://llms-explorer.com/tree/time-series-cardinality-and-metafield-design/ · pack 2026-10-23 · ~875 tokens -->

# Time series cardinality and metaField design

> Source-anchored research for Time series cardinality and metaField design. Run status: COMPLETED.

Parent: [Bucket catalog memory and closure reasons](https://llms-explorer.com/tree/bucket-catalog-memory-and-closure-reasons/) · 4 facets · 8 facts · page: https://llms-explorer.com/tree/time-series-cardinality-and-metafield-design/

## How it works

- Measurements share a bucket only when their complete metaField values are identical and their timestamps are close. Fine-grained or changing metadata can create more sparse, short-lived buckets and reduce storage and query efficiency. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-considerations/)
- MongoDB groups measurements into a bucket when they have an identical metaField value and timeField values that are close together; for object or array metadata, all fields or elements must match. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-bucketing.md)
- HiveMQ's manufacturing example places asset and process context under the metaField for a time-series collection; because the example does not specify how often each process field changes, check those update rates against MongoDB's recommendation to use metadata that rarely changes. (medium confidence) (verified as of 2026-10-20) — [source](https://www.hivemq.com/blog/mongodb-data-modeling-manufacturing-iiot/)

## Problems, failure modes and limitations

- A distinct sensor or device identifier can still be a suitable metaField when it identifies a stable series; the design risk is fine-grained or rapidly changing metadata that fragments measurements, not uniqueness by itself. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-bucketing.md)

## Comparisons and alternatives

- The cited MongoDB guidance gives qualitative advice rather than a numeric maximum for distinct metaField values, and it states that compressed bucket formats support high-cardinality workloads; treat blanket claims that high cardinality is always harmful as too broad. (medium confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-considerations/)
- MongoDB supports an object-valued metaField, but recommends querying scalar subfields instead of matching the whole object because field ordering may vary. For manufacturing sensor data, HiveMQ's IIoT guide places asset and process context under the metadata field while keeping timestamp, metric, and value separate. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-considerations/)

## Facts and statements

- Choose stable identifiers and metadata used in common filters for the metaField. Keep measurements, timestamps, and fields that queries do not use for filtering outside it, so changing or per-event values do not split otherwise related measurements into distinct metadata groups. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-considerations/)
- Fine-grained or changing metaField values produce more sparsely packed, short-lived buckets and typically reduce storage and query efficiency. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-considerations/)
