How does MongoDB compare values of different BSON types when matching and sorting?

## No implicit coercion The single most important fact is negative: MongoDB does not convert types to make a comparison succeed. The query `{ qty: 100 }` matches documents where `qty` is the number 100 — as an int, a long, a double or a decimal — and does **not** match a document where `qty` is the string `"100"`. Nothing warns you; the document simply is not in the result. The same holds for a date compared with its string rendering, or a boolean compared with 1. This is what makes a schemaless store demand type discipline. A field whose type varies across documents is not merely untidy: it silently splits your data into partitions your queries can only reach one at a time. ## The cross-type ordering Comparison still has to be **total**, because indexes and `sort()` must place every value somewhere. MongoDB therefore ranks the BSON types, from lowest to highest: 1. MinKey (internal) 2. Null 3. Numbers (int, long, double, decimal) 4. String 5. Object (embedded document) 6. Array 7. BinData 8. ObjectId 9. Boolean 10. Date 11. Timestamp 12. Regular expression 13. MaxKey So in an ascending sort every number precedes every string, which precedes every embedded document, and so on. Two useful corollaries: `{ f: { $gt: 5 } }` cannot return a string, because strings rank above all numbers but the predicate is evaluated within the number band; and sorting a mixed-type field produces clean per-type blocks rather than an interleaving. ## Numbers are one band All four numeric types compare against each other **by value**: `NumberInt(5)`, `NumberLong(5)` and `5.0` are equal, and a range predicate spans them all. The comparison is performed exactly, which is why a `double` literal and a `Decimal128` holding the "same" decimal amount are *not* equal — the double's exact binary value differs from the decimal's. That is a numeric-precision consequence, not an exception to the type rule. ## Missing fields, null, and arrays For ordering purposes, a **missing field is treated as null**, so documents lacking the sort key cluster with the explicit nulls at the low end of an ascending sort. **Arrays** get special treatment. For an ascending sort, an array is represented by its **smallest** element; for a descending sort, by its **largest**. And in matching, a query predicate on a field holding an array succeeds if *any* element satisfies it, which is why `{ tags: "db" }` matches `{ tags: ["db", "nosql"] }` without any special operator. **Embedded documents** compare field by field in the order the fields appear in the BSON, comparing field names and then values. That means two documents with the same fields written in a different order are different values — a real trap when an embedded document is used as an `_id` or as an equality target. ## Diagnosing and repairing mixed types The `$type` operator is the audit tool. `{ field: { $type: "string" } }` isolates the string-typed strays; the alias `{ field: { $type: "number" } }` matches int, long, double and decimal together, so `{ field: { $not: { $type: "number" } } }` finds everything that is not numeric at all. `$type` also accepts an array of type names. Repair is an update that uses an aggregation pipeline (supported from MongoDB 4.2 onward), which lets the new value be computed from the old one: ```javascript db.orders.updateMany( { qty: { $type: "string" } }, [{ $set: { qty: { $toInt: "$qty" } } }] ) ``` For values that may not convert cleanly, `$convert` takes `onError` and `onNull` so a bad row can be routed to a sentinel instead of failing the whole batch. ## Preventing recurrence Once repaired, the way to keep a field single-typed is to declare it — a collection validator that pins `bsonType` rejects the next writer that sends a string. Type discipline at the boundary (wrapping values in the right constructor in application code) is the other half; the database can only reject what reaches it.