Does the 1 or -1 direction matter when creating a single-field MongoDB index?
answer
- Think about which way you can read a sorted list
- Index keys live in one ordering, two readings
- Only matters once two keys are involved
- Watch the auto-generated index name
- Compound sorts are where direction bites
basics
~20 sNo. For a single-field index MongoDB can walk the keys forward or backward, so createIndex({ createdAt: 1 }) and createIndex({ createdAt: -1 }) serve exactly the same queries and both sort directions. Direction only starts to matter in compound indexes.
solid answer
~50 sFor a **single-field** index the direction is cosmetic. The index keys are stored in sorted order and MongoDB can traverse that ordering in either direction, so `{ createdAt: 1 }` and `{ createdAt: -1 }` support the same equality filters, the same range filters, and both `sort({ createdAt: 1 })` and `sort({ createdAt: -1 })`. The two specs differ only in the auto-generated index name (`createdAt_1` vs `createdAt_-1`), which is how teams end up with two identical indexes by accident — one of them is pure write overhead and should be dropped. Direction becomes meaningful in a **compound** index, where the relative directions of the keys decide which multi-field sorts the index can satisfy without an in-memory sort. Also worth saying out loud: every collection already has a unique index on `_id` that you cannot drop.
go deeper
Recall the flat fact: for one field, 1 and -1 serve the same queries and both sort orders. Also remember that _id is indexed automatically and you never create that index yourself.
Explain why the ordering can be read either way, and be ready to show the compound case where relative key directions decide which sorts avoid an in-memory sort.
Point out the real production cost: duplicate field_1 and field_-1 definitions are pure write amplification with no read benefit, and show how you would spot and drop one safely.
Own the standard: index specs are reviewed like schema, with naming and review conventions that stop near-duplicate indexes accumulating across teams over years.
## What a single-field index is A single-field index is created with `db.collection.createIndex({ <field>: 1 })` or `{ <field>: -1 }`. MongoDB builds an ordered B-tree structure whose keys are the values of that field (in BSON sort order) and whose entries point back at the documents that contain them. Any query that filters on that field — equality, `$in`, `$gt`/`$lt` ranges — can be answered by seeking into the tree and walking the matching key range instead of reading every document. ## Why the direction is irrelevant for one field The leaf level of the index is an ordered sequence of keys, and that sequence can be scanned from either end. "Ascending" and "descending" describe the same ordering read in opposite directions. So an index declared `{ createdAt: 1 }` serves `find().sort({ createdAt: -1 })` perfectly: MongoDB simply walks the keys backwards. The same is true for range predicates — a range is a contiguous stretch of keys regardless of which way you enter it. The practical consequences: - Both specs have identical size, identical write cost, and identical selectivity. - Both support both sort directions and all the same filters. - They are *different index definitions* to the server. The default name is derived from the spec, so `createdAt_1` and `createdAt_-1` can coexist. That is a redundant pair: every insert and every update of `createdAt` maintains both, for zero read benefit. ## Where direction genuinely matters Direction is load-bearing only when a single index has to satisfy a sort over **more than one** field. An index on `{ userId: 1, createdAt: -1 }` can serve `sort({ userId: 1, createdAt: -1 })` by walking forward and `sort({ userId: -1, createdAt: 1 })` by walking backward — the exact inverse of every key. It cannot serve `sort({ userId: 1, createdAt: 1 })` from the index alone, because that mixes directions in a way no single traversal produces. So when you design a compound index for a sort, the relative directions of the keys have to match the sort (or be its exact mirror). ## Directions that are not directions Not every index spec value is `1` or `-1`. MongoDB also has special single-field index types whose "direction" slot carries a type name instead: - `{ field: "hashed" }` — stores a hash of the value. It supports equality matching only; ranges and sorts cannot use it, because hashing destroys the ordering. Its main use is spreading a monotonically increasing key evenly. - `{ field: "text" }` — a text index for `$text` searching. - `{ location: "2dsphere" }` — a geospatial index over GeoJSON. Asking about ascending versus descending for those is a category error; there is no ordering to reverse. ## The `_id` index Every collection gets a unique index on `_id` at creation, automatically, and it cannot be dropped. That is why lookups by `_id` are always fast, and why you never need to create that index yourself. ## How to answer this in an interview Say "no, not for a single field — MongoDB reads the index in either direction," then immediately volunteer the two follow-on facts that show you understand *why*: direction matters in compound indexes because a multi-key sort must match the index ordering or its exact inverse, and the only real hazard of the two specs is accidentally creating both and paying twice on writes.
- So when does the direction of an index key actually change what the index can do?In a compound index, when the index has to satisfy a multi-field sort. An index on { userId: 1, createdAt: -1 } serves sort({ userId: 1, createdAt: -1 }) walking forward and sort({ userId: -1, createdAt: 1 }) walking backward, because that is the exact inverse. It cannot serve sort({ userId: 1, createdAt: 1 }) from the index, because no single traversal produces mixed directions.
- What is different about a hashed index on a single field?The spec is { field: "hashed" }, and the index stores a hash of the value rather than the value itself. Hashing destroys the ordering, so the index can serve equality matches but not range filters and not sorts. Its usual purpose is distributing an otherwise monotonically increasing key evenly rather than accelerating range scans.
- Do you ever need to create an index on _id?No. Every collection is created with a unique index on _id, and that index cannot be dropped. Creating your own index on _id is redundant. You can still add compound indexes whose first key is _id if a query pattern needs one, but the plain single-field one is already there.
saying these in an interview costs you the question
- Claims an ascending index cannot serve a descending sort
- Creates both field_1 and field_-1 for the same field
- Thinks direction changes index size or selectivity
- Believes direction is meaningless even in compound indexes
- Manually creates an index on _id