Multikey and Array Indexes

What we're doing: Show an index quietly becoming multikey after an initial run of scalar-only inserts.

db.products.createIndex({ tags: 1 })

db.products.insertOne({ _id: 1, tags: "electronics" })   // scalar — index not yet multikey
db.products.insertOne({ _id: 2, tags: "sale" })           // still scalar

db.products.insertOne({ _id: 3, tags: ["electronics", "sale"] })  // array — index is now multikey

1

The index definition itself gives no indication of whether it will ever be multikey — that depends entirely on the data inserted afterward.

5

This single array-valued insert is what flips the index's status — nothing about the createIndex call or the two prior scalar inserts predicted it.

Why this works: Because MongoDB is schema-flexible, "this field is always a scalar" is an assumption about the data, not a guarantee the database enforces on its own — multikey status quietly tracks whatever the data actually turns out to be, which is exactly why a validator is the tool for enforcing the assumption if it needs to hold.

What we're doing: Show the hashed-index rejection concretely, and a sort on a multikey field that needs checking via explain().

db.products.createIndex({ tags: "hashed" })
db.products.insertOne({ tags: ["sale", "clearance"] })
// -> fails: hashed indexes do not support array values

db.products.find({ category: "electronics" }).sort({ tags: 1 })
// -> check explain(): the sort on a multikey field frequently shows an in-memory SORT stage

1

A hashed index and multikey are fundamentally incompatible — this insert fails regardless of how the index was intended to be used.

5

Even with tags indexed, sorting by it does not reliably get to skip the in-memory sort the way a scalar field would — explain() is the only way to confirm which actually happened for a given query.

Why this works: Both restrictions exist for the same reason: a hash needs exactly one value to hash per document, and an index-supported sort needs exactly one position per document — an array field can supply several values, breaking both assumptions, so MongoDB restricts the hashed case outright and falls back to memory for the sort case rather than producing an ambiguous result.

What we're doing: Show the exact failure when an update would make a second field in the same compound index become an array.

db.movies.createIndex({ genres: 1, year: 1 })
db.movies.insertOne({ _id: 1, genres: ["Drama", "Action"], year: 2020 })   // ok — one array field

// Later, an update tries to also make year an array on the same document:
db.movies.updateOne({ _id: 1 }, { $set: { year: [2020, 2021] } })
// -> fails: "cannot index parallel arrays" — genres and year would both be arrays on this document

1

This document starts compliant — only genres is an array, year is a scalar.

5

The update would make year an array too, which the compound index cannot represent — MongoDB rejects the write rather than silently allowing an ambiguous index state.

Why this works: The failure happens at the moment the violation would actually occur — whether that is the initial insert, a later update, or the createIndex call itself if the data already violates the rule — which is why "which of these fields was last modified" is not what determines the error, "would this document end up with two array fields in the index" is.

What we're doing: Contrast index entry counts for the same document count under two different array-length assumptions.

// 100,000 products, each with a 3-element "tags" array:
// -> roughly 300,000 index entries for the tags index

// 100,000 products, each with a 200-element "reviewIds" array (unbounded growth):
// -> roughly 20,000,000 index entries for the reviewIds index — the same document count, vastly larger index

2

A modest, bounded array (a handful of tags) keeps the multikey index proportionally close to document count.

5

An unbounded or large array multiplies index size by its average length — the same 100,000 documents produce a vastly larger index once the array itself is large.

Why this works: This is the concrete mechanism behind why "index this array field" is not automatically a good idea for every array — an unbounded or high-cardinality array turns "one index per field" into an index whose real size depends on data growth, not schema shape.

What we're doing: Show an indexed array kept bounded by $slice, versus the unbounded alternative and its compounding cost.

// Bounded: the index for recentSearches never grows past 20 entries per user, no matter how many searches happen
db.users.createIndex({ recentSearches: 1 })
db.users.updateOne({ _id: u }, { $push: { recentSearches: { $each: [term], $slice: -20 } } })

// Unbounded: every search ever made grows both the document and this index forever
db.users.createIndex({ allSearchesEver: 1 })
db.users.updateOne({ _id: u }, { $push: { allSearchesEver: term } })

2

The $slice: -20 cap means this user's contribution to the multikey index never exceeds 20 entries, regardless of account age.

6

Without a cap, this field's contribution to the multikey index — and the document's own size — both grow for as long as the account exists, compounding the same unbounded-growth risk in two places.

Why this works: Bounding an array before indexing it addresses the document-growth and index-growth costs together, since they share the same cause — this is a case where one design decision (cap the array) resolves two distinct, additive costs at once.