Online Archive partition-field selection
Parent: Storage and Data-Lifecycle Cost Levers · Published reference · snapshot 2026-10-21 · skill ranked-ab842e47
↓ Facts as markdownall context files
Source-anchored research for Online Archive partition-field selection. 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.
Definitions
- Partition fields are an archive-query cost lever. Atlas organizes archived data by the configured fields, can target matching partitions, and charges for each partition queried. Queries that omit the configured fields can require a full scan of archived documents, increasing scan time and query cost. (high confidence) (verified as of 2026-10-14) [source]
Structure and components
- Atlas does not allow partition fields or partition structure to be modified through the UI or API after archive creation. Changing the layout requires migrating or rehydrating the archived data, deleting the archive, and creating a new one, so review actual archive queries before selecting fields. (high confidence) (verified as of 2026-10-14) [source]
How-to and procedures
- Use explain to inspect which data partitions Atlas used for a query before deciding whether a proposed field order prunes the expected archive data. (low confidence) [source]
- Use consistently typed partition values from Atlas's supported types: date, double, int, long, objectId, string, or boolean. Atlas warns that polymorphic values may prevent documents with mismatched values from archiving. The current Pulumi provider documentation also says partition values longer than 700 characters are not archived. (medium confidence) (verified as of 2026-10-13) [source]
Problems, failure modes and limitations
- Current configuration limits allow up to two non-date query fields, or up to three partition fields when one is the Date Match field; the date field must be included for Date Match archives. Treat the limit as a ceiling and choose only fields that match real archive-query patterns. (high confidence) (verified as of 2026-10-14) [source]
- MongoDB's current guide scopes its warning about high-cardinality string partition fields creating many partitions to archives created before June 2023 and says that warning does not apply to archives created after that date. The release post attributes newer archives' performance improvements to a metadata-capturing storage engine. (high confidence) (verified as of 2026-10-14) [source]
- Apply cardinality guidance by archive generation. MongoDB's current docs say the high-cardinality string partition warning applies to archives created before June 2023 and does not apply to archives created after that date. A 2021 guide's general preference for moderate-to-high cardinality fields and warning about extreme-cardinality _id keys describe the earlier behavior. (medium confidence) (verified as of 2026-10-14) [source]
Comparisons and alternatives
- Choose supported scalar partition fields with consistent values. Atlas samples 10 documents to determine a field's type and does not archive documents whose field type differs from the collection's sampled type; a MongoDB community response also says arrays and objects cannot be partition fields. (medium confidence) (verified as of 2026-10-14) [source]
Facts and statements
- Choose keys from filters used most often on archived queries, then order them from most to least frequently queried. With Date Match, the date field defaults to the first position but can move later if another filter is used more often. A query that skips an earlier key can use later partitions less efficiently; including all configured keys in order minimizes data scanned. (high confidence) [source]
- Atlas partitions in field order, so queries that filter on leading fields in that order can target narrower partition prefixes. Queries that omit leading partition fields or use fields without partitions get less efficient pruning, and queries without partition fields can scan all archived documents. (high confidence) [source]
Children
- No children recorded.