The $toLong operator converts values to a 64-bit long integer in MongoDB aggregation pipelines. Use it for large user IDs, Unix millisecond timestamps, and any whole number that exceeds the 32-bit int range.
Values to int64.
One expression.
Beyond int32 range.
Parse big IDs.
Timestamps, IDs.
64-bit vs 32-bit.
In MongoDB’s aggregation framework, the $toLong operator converts an expression to a 64-bit signed long integer. While $toInt handles values up to about 2.1 billion, many real-world datasets store larger numbers — snowflake IDs, Unix timestamps in milliseconds, and high-volume counters all need the wider range that $toLong provides.
$toLong is shorthand for { $convert: { input: <expression>, to: "long" } }. Like $toInt, it truncates doubles toward zero when converting fractional numbers to whole numbers.
JavaScript Date.now() returns milliseconds like 1718448600000 — too large for int32. Use $toLong for these timestamp values.
The $toLong operator takes one expression:
{ $toLong: <expression> }{ $toLong: "9876543210987" }
// Result: NumberLong(9876543210987)
{ $toLong: 1718448600000 }
// Result: NumberLong(1718448600000)
{ $toLong: "$userId" }
// Convert the userId field
{ $toLong: "$timestampMs" }
// Parse millisecond timestampnull — returns null.true becomes 1, false becomes 0.$project, $addFields, $set, or $group.1718448600000 (Unix ms) fits in long but overflows int32| Question | Answer |
|---|---|
| Operator type | Aggregation expression operator (type conversion) |
| Syntax | { $toLong: <expression> } |
| Output type | 64-bit signed integer (long / int64) |
| Equivalent | { $convert: { input: <expr>, to: "long" } } |
| Max value | 9,223,372,036,854,775,807 |
| Common stages | $project, $addFields, $group |
{
$toLong: "$userId"
}Large user ID
{
$toLong: "$timestampMs"
}Unix milliseconds
{
$sum: {
$toLong: "$views"
}
}Total large counts
{
$toLong: "3000000000"
}Beyond int32
Parse large user IDs, convert Unix millisecond timestamps, sum high-volume counters, and compare long vs int conversion limits.
Start with a users collection where large IDs are stored as strings and convert them with $toLong.
Suppose you have a users collection with snowflake-style IDs stored as strings:
[
{
"_id": 1,
"name": "Alice",
"userId": "9876543210987",
"lastSeenMs": "1718448600000"
},
{
"_id": 2,
"name": "Bob",
"userId": "9876543210999",
"lastSeenMs": "1718535000000"
},
{
"_id": 3,
"name": "Carol",
"userId": "9876543211001",
"lastSeenMs": "1718621400000"
}
]Parse the userId string into a 64-bit long integer:
db.users.aggregate([
{
$project: {
name: 1,
userId: 1,
userIdLong: { $toLong: "$userId" }
}
}
])Values like 9876543210987 exceed the int32 maximum (~2.1 billion). $toLong handles them; $toInt would fail or overflow.
Convert millisecond timestamps, sum large counters, and sort numerically.
Parse timestamp strings that are too large for int32:
db.users.aggregate([
{
$project: {
name: 1,
lastSeenMs: 1,
lastSeenLong: { $toLong: "$lastSeenMs" }
}
}
])
// "1718448600000" → NumberLong(1718448600000)
// Too large for $toInt (max ~2147483647)Unix timestamps in milliseconds are common in JavaScript and API data. They always need long (or double), not int32.
Convert timestamp strings, then sort by most recent activity:
db.users.aggregate([
{
$addFields: {
lastSeenLong: { $toLong: "$lastSeenMs" }
}
},
{
$sort: { lastSeenLong: -1 }
},
{
$project: {
name: 1,
lastSeenLong: 1
}
}
])Sorting string timestamps alphabetically gives wrong order. Converting to long first ensures correct chronological sorting.
Aggregate page view counts stored as strings:
db.analytics.aggregate([
{
$group: {
_id: "$pageId",
totalViews: {
$sum: { $toLong: "$views" }
}
}
},
{
$sort: { totalViews: -1 }
}
])
// Sums view counts that may exceed int32 rangeHigh-traffic pages can accumulate billions of views. $toLong ensures the sum stays accurate without int32 overflow.
See why large values need long instead of int:
db.test.aggregate([
{
$project: {
value: "3000000000",
asLong: { $toLong: "3000000000" },
asIntAttempt: {
$convert: {
input: "3000000000",
to: "int",
onError: "overflow"
}
}
}
}
])
// asLong: NumberLong(3000000000) ✓
// asIntAttempt: "overflow" (exceeds int32 max of 2147483647)Three billion exceeds int32’s ~2.1 billion limit. $toLong handles it; $toInt fails or overflows.
When values may be invalid, use $convert with onError:
db.users.aggregate([
{
$project: {
name: 1,
userIdLong: {
$convert: {
input: "$userId",
to: "long",
onError: 0,
onNull: 0
}
}
}
}
])
// "9876543210987" → NumberLong(9876543210987)
// "invalid" → 0 (fallback)
// null → 0$toLong errors on invalid strings. $convert with onError lets the pipeline continue with a safe default.
Date.now() values for sorting and comparison.$toLong WorksThe input resolves from a field path, numeric string, number, boolean, or nested expression.
Strings are parsed; doubles and decimals are truncated toward zero; booleans become 0 or 1.
The output supports $add, $sum, sorting, and comparisons on large whole numbers.
Use for big IDs, timestamps, counters, and int64 arithmetic.
The $toLong operator converts values to 64-bit long integers in MongoDB aggregation pipelines. It is essential for snowflake IDs, Unix millisecond timestamps, and any whole number that exceeds the 32-bit int range.
For smaller whole numbers, $toInt is sufficient. For decimal fractions, use $toDouble. For conversions with error handling, use $convert. Next in the series: $toLower.
$toLong for Unix millisecond timestamps$convert with onError for messy imported data$toInt when values fit in the 32-bit range$toInt for values above ~2.1 billion$toLong when you need decimal fractions$toLongUse these points when converting values to long integers in MongoDB.
64-bit long.
PurposeOne argument.
SyntaxIDs, timestamps.
InputParse then use.
Usage64 vs 32 bit.
RangeMove on to $toLower for string case conversion, or review $toInt for 32-bit integers.
5 people found this page helpful