Comparison Operators: $eq, $gt, $lt, $in

Simple equality filters like { status: 'active' } are useful, but real queries need more nuance. MongoDB provides a rich set of query operators prefixed with $ that express conditions beyond simple equality. These operators let you filter by numeric ranges, membership in a list, value presence, and pattern matching.

Comparison operators are the most commonly used category. They work on any comparable BSON type: numbers, strings (lexicographic comparison), dates, and even ObjectIds (chronological order, since ObjectIds encode timestamps).

The $eq operator explicitly tests for equality: { age: { $eq: 30 } }. In most cases, the shorthand { age: 30 } is identical and preferred for readability—$eq is mainly useful when the operator is needed inside another expression like $expr.

One difference: $eq inside aggregation pipeline expressions is required when comparing two field values (e.g., { $eq: ['$price', '$salePrice'] }). In regular find filters, stick to the shorthand equality syntax unless a specific context requires the operator form.

$gt (greater than) and $gte (greater than or equal) filter documents where a field's value exceeds a threshold. These work on numbers, dates, strings (lexicographic order), and ObjectIds.

Date comparisons are particularly powerful: { createdAt: { $gte: new Date('2024-01-01') } } finds all documents created since January 1, 2024. This query can use an index on createdAt for O(log n) performance, making date-range queries extremely efficient even on large collections.

$lt (less than) and $lte (less than or equal) are the complements of $gt/$gte. Combine both operators on the same field to create a range query—MongoDB applies both conditions to the same field, equivalent to SQL's BETWEEN.

Range queries on indexed fields are very efficient because MongoDB can seek to the lower bound in the index and scan forward to the upper bound, touching only the relevant entries. This is one of the primary reasons to index fields you frequently filter by range.

$ne (not equal) matches documents where a field's value is not equal to the specified value. It also matches documents where the field does not exist at all—because a missing field is implicitly not equal to any value.

Be cautious with $ne on large, unindexed collections: MongoDB typically cannot use an index to satisfy a negation efficiently and may fall back to a collection scan. For heavily filtered queries, prefer positive conditions ($eq, $in) over negative ones when possible.

$in matches documents where a field's value equals any value in a provided array. It is the MongoDB equivalent of SQL's IN clause. This is far more concise than writing multiple $or conditions for the same field.

On an indexed field, $in is implemented as multiple point lookups in the index tree—one per value in the array—which is very efficient. For large lists (hundreds of values), performance degrades, but for typical use cases (5-20 values), $in is a great choice.

$nin (not in) is the negation of $in—it matches documents where the field's value is not in the provided array (and also matches documents where the field is absent). Like $ne, it can be less efficient than $in because it often requires scanning documents.

A practical use case: excluding a known set of IDs. If a user has blocked certain other users, you might exclude their content: { authorId: { $nin: blockedUserIds } }. Keep the exclusion list small for best performance.

You can combine multiple comparison operators on the same field or different fields in a single query. When operators appear on the same field in one object, they act as an implicit AND—both conditions must be true. When they are on different fields, both conditions must also be true.

Build complex filters by thinking about each field independently and combining conditions. MongoDB evaluates all field conditions together, using indexes where available to minimize the documents examined.

Date comparisons are among the most common uses of comparison operators in real applications. MongoDB's Date BSON type stores dates as 64-bit milliseconds, so all comparison operators work naturally on date fields.

Common patterns include: finding records created in the last N days, filtering active subscriptions that expire after today, and range queries for reporting periods. Always construct Date objects in the query—never compare dates as strings, as lexicographic string comparison gives incorrect results for most date formats.

Comparison operators benefit enormously from indexes. An index on a numeric field turns an O(n) scan into O(log n + result size). Key points:

• Range queries ($gt, $lt) can use a single-field index to navigate directly to the range start
• $in performs multiple point lookups in the index—one per value
• Negation operators ($ne, $nin) often scan the index rather than using point lookups, so they are less efficient
• Use explain('executionStats') to verify your comparison queries use IXSCAN and not COLLSCAN

Comparison operators appear in two contexts: as query operators in find() filters (with the syntax { field: { : value } }) and as expression operators in the aggregation pipeline and stages (with a different syntax: { : ['', value] }).

In , expression operators return a boolean or a computed value. For example, you can add a computed field isExpensive that is true when price exceeds 100: { : { isExpensive: { : ['', 100] } } }. The stage uses the same query syntax as find().

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: $gt/$gte/$lt/$lte create range conditions on numbers, dates, and strings, and work with indexes for O(log n) range scans, $in matches any value from a list and is significantly more readable and efficient than multiple $or equality conditions on the same field, and $ne/$nin are negation operators that match anything outside the given value/list but are less index-efficient than their positive counterparts. Next up we explore logical operators—$and, $or, $nor, and $not—to combine conditions across different fields.