If you test $isArray: [42] in MongoDB, it returns false and that's the right answer. If you test $isArray: [42,42,42] you get an error telling you that Expression $isArray takes exactly 1 arguments, but 3 were passed in. Documentation about $isArray explains that the input is interpreted as multiple arguments rather than a single argument that is an array:

Aggregation expressions accept a variable number of arguments. These arguments are normally passed as an array. However, when the argument is a single value, you can simplify your code by passing the argument directly without wrapping it in an array.

The documentation about the Expression Operator clarifies that when passing a single argument that is an array, you must use $literal or wrap the array in an additional array that will be interpreted by the language:

Here are a few reproducible examples (also available here) to explain it.

Expression Operator with literals

I use a collection with one document to run my expressions in an aggregation pipeline:

db.dual.insertOne( { "dummy": "x" } )

{
  acknowledged: true,
  insertedId: ObjectId('687d09913b111f172ebaa8ba')
}

$isNumber takes one argument and returns true if it is a number:

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: [ 42 ]       // one argument -> number
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': true } ]

The array that you see in $isNumber: [ 42 ] is interpreted as a list of arguments for the expression operator. Text-based languages would use isNumber(42) but MongoDB query language is structured into BSON to better integrate with application languages and be easily parsed by the drivers.

Trying to pass two arguments raises an error:

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: [ 42 , 42 ]  // two arguments -> error
      }, "_id": 0
    }
  }
])

MongoServerError[Location16020]: Invalid $project :: caused by :: Expression $isNumber takes exactly 1 arguments. 2 were passed in.

For expression operators that take one argument, you can pass it as a value rather than as an array, but this is just a syntactic shortcut and doesn't change the data type of the argument:

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: 42           // one argument -> number    
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': true } ]

$isArray takes a single argument and returns true if that argument is an array. However, in the examples above, the array syntax is used to structure the list of arguments rather than define a literal array data type:

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: [ 42 ]       // one argument -> number
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': false } ]


db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: [ 42 , 42 ]  // two arguments -> error
      }, "_id": 0
    }
  }
])

MongoServerError[Location16020]: Invalid $project :: caused by :: Expression $isArray takes exactly 1 arguments. 2 were passed in.

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: 42           // one argument -> number
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': false } ]

If you want to pass an array as an argument, you must nest the data array inside another array, which structures the list of arguments:

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: [ [ 42 ] ]   // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': true } ]

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: [ [ 42 ] ]  // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': false } ]

Another possibility is using $literal, which doesn't take a list of arguments, but rather avoids parsing an array as a list of arguments:

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: { $literal: [ 42 ] }  // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': true } ]

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: { $literal: [ 42 ] }  // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': false } ]

This can be confusing. I wrote this while answering a question on Bluesky:

#MongoDB seriously, why? $isNumber: 5 → true $isArray: [] → false $isArrau: [[5]] → true

— Ivan “CLOVIS” Canet (@ivcanet.bsky.social) 2025-07-08T18:54:24.735Z

All languages exhibit certain idiosyncrasies where specific elements must be escaped to be interpreted literally rather than as language tokens. For instance, in PostgreSQL, a literal array must follow a specific syntax:

postgres=> SELECT pg_typeof(42) AS "is 42 a number?";

 is 42 a number?
-----------------
 integer

postgres=> SELECT pg_typeof(42, 42);

ERROR:  function pg_typeof(integer, integer) does not exist
LINE 1: SELECT pg_typeof(42, 42);
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

postgres=> SELECT pg_typeof(ARRAY[42]);

 pg_typeof
-----------
 integer[]

postgres=> SELECT pg_typeof('{42}'::int[]);

 pg_typeof
-----------
 integer[]

main=> SELECT pg_typeof('{''42'',''42''}'::text[]);
 pg_typeof
-----------
 text[]

Additionally, in SQL, using double quotes serves to escape language elements, so that during parsing, they are interpreted as data or as part of the language syntax. In PostgreSQL the ambiguity is between text and array, in MongoDB it is between arguments and arrays.

You typically shouldn't encounter issues with MongoDB in common situations because expression operators are designed for expressions rather than literals. For instance, you don't need to call the database to know that 42 is a number and [] is an array. If this was generated by a framework, it likely uses $literal for clarity. If it is coded for expressions, there's no ambiguity.

Expression Operator with expressions

I use a collection containing one document with a field that is an array:

db.arrays.insertOne( { "field": [42] } )

{
  acknowledged: true,
  insertedId: ObjectId('687d1c413e05815622d4b0c2')
}

I can pass the "$field" expression argument to the operator and it remains an array:

db.arrays.aggregate([
{
    $project: {
      field: 1,
      " is $field a number?": {
        $isNumber: "$field"        // one argument -> expression    
      },
      " is $field an array?": {
        $isArray: "$field"         // one argument -> expression    
      },
      "_id": 0
    }
  }
])

[
  {
    field: [ 42 ],
    ' is $field a number?': false,
    ' is $field an array?': true
  }
]

In this case, using the one argument shortcut ("$field") or an array (["$field"]) doesn't matter because there's a clear distinction between language elements and data.

In short, with expressions that return arrays when executed, there's no problem, and for array literal, use $literal.

If you test $isArray: [42] in MongoDB, it returns false and that's the right answer. If you test $isArray: [42,42,42] you get an error telling you that Expression $isArray takes exactly 1 arguments, but 3 were passed in. Documentation about $isArray explains that the input is interpreted as multiple arguments rather than a single argument that is an array:

Aggregation expressions accept a variable number of arguments. These arguments are normally passed as an array. However, when the argument is a single value, you can simplify your code by passing the argument directly without wrapping it in an array.

The documentation about the Expression Operator clarifies that when passing a single argument that is an array, you must use $literal or wrap the array in an additional array that will be interpreted by the language:

Here are a few reproducible examples (also available here) to explain it.

Expression Operator with literals

I use a collection with one document to run my expressions in an aggregation pipeline:

db.dual.insertOne( { "dummy": "x" } )

{
  acknowledged: true,
  insertedId: ObjectId('687d09913b111f172ebaa8ba')
}

$isNumber takes one argument and returns true if it is a number:

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: [ 42 ]       // one argument -> number
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': true } ]

The array that you see in $isNumber: [ 42 ] is interpreted as a list of arguments for the expression operator. Text-based languages would use isNumber(42) but MongoDB query language is structured into BSON to better integrate with application languages and be easily parsed by the drivers.

Trying to pass two arguments raises an error:

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: [ 42 , 42 ]  // two arguments -> error
      }, "_id": 0
    }
  }
])

MongoServerError[Location16020]: Invalid $project :: caused by :: Expression $isNumber takes exactly 1 arguments. 2 were passed in.

For expression operators that take one argument, you can pass it as a value rather than as an array, but this is just a syntactic shortcut and doesn't change the data type of the argument:

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: 42           // one argument -> number    
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': true } ]

$isArray takes a single argument and returns true if that argument is an array. However, in the examples above, the array syntax is used to structure the list of arguments rather than define a literal array data type:

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: [ 42 ]       // one argument -> number
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': false } ]


db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: [ 42 , 42 ]  // two arguments -> error
      }, "_id": 0
    }
  }
])

MongoServerError[Location16020]: Invalid $project :: caused by :: Expression $isArray takes exactly 1 arguments. 2 were passed in.

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: 42           // one argument -> number
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': false } ]

If you want to pass an array as an argument, you must nest the data array inside another array, which structures the list of arguments:

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: [ [ 42 ] ]   // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': true } ]

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: [ [ 42 ] ]  // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': false } ]

Another possibility is using $literal, which doesn't take a list of arguments, but rather avoids parsing an array as a list of arguments:

db.dual.aggregate([
{
    $project: {
      " is 42 an array?": {
        $isArray: { $literal: [ 42 ] }  // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 an array?': true } ]

db.dual.aggregate([
{
    $project: {
      " is 42 a number?": {
        $isNumber: { $literal: [ 42 ] }  // one argument -> array
      }, "_id": 0
    }
  }
])

[ { ' is 42 a number?': false } ]

This can be confusing. I wrote this while answering a question on Bluesky:

#MongoDB seriously, why? $isNumber: 5 → true $isArray: [] → false $isArrau: [[5]] → true

— Ivan “CLOVIS” Canet (@ivcanet.bsky.social) 2025-07-08T18:54:24.735Z

All languages exhibit certain idiosyncrasies where specific elements must be escaped to be interpreted literally rather than as language tokens. For instance, in PostgreSQL, a literal array must follow a specific syntax:

postgres=> SELECT pg_typeof(42) AS "is 42 a number?";

 is 42 a number?
-----------------
 integer

postgres=> SELECT pg_typeof(42, 42);

ERROR:  function pg_typeof(integer, integer) does not exist
LINE 1: SELECT pg_typeof(42, 42);
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

postgres=> SELECT pg_typeof(ARRAY[42]);

 pg_typeof
-----------
 integer[]

postgres=> SELECT pg_typeof('{42}'::int[]);

 pg_typeof
-----------
 integer[]

main=> SELECT pg_typeof('{''42'',''42''}'::text[]);
 pg_typeof
-----------
 text[]

Additionally, in SQL, using double quotes serves to escape language elements, so that during parsing, they are interpreted as data or as part of the language syntax. In PostgreSQL the ambiguity is between text and array, in MongoDB it is between arguments and arrays.

You typically shouldn't encounter issues with MongoDB in common situations because expression operators are designed for expressions rather than literals. For instance, you don't need to call the database to know that 42 is a number and [] is an array. If this was generated by a framework, it likely uses $literal for clarity. If it is coded for expressions, there's no ambiguity.

Expression Operator with expressions

I use a collection containing one document with a field that is an array:

db.arrays.insertOne( { "field": [42] } )

{
  acknowledged: true,
  insertedId: ObjectId('687d1c413e05815622d4b0c2')
}

I can pass the "$field" expression argument to the operator and it remains an array:

db.arrays.aggregate([
{
    $project: {
      field: 1,
      " is $field a number?": {
        $isNumber: "$field"        // one argument -> expression    
      },
      " is $field an array?": {
        $isArray: "$field"         // one argument -> expression    
      },
      "_id": 0
    }
  }
])

[
  {
    field: [ 42 ],
    ' is $field a number?': false,
    ' is $field an array?': true
  }
]

In this case, using the one argument shortcut ("$field") or an array (["$field"]) doesn't matter because there's a clear distinction between language elements and data.

In short, with expressions that return arrays when executed, there's no problem, and for array literal, use $literal.

In a previous post about No-gap sequence in PostgreSQL and YugabyteDB, I mentioned that sequences in SQL databases are not transactional, which can lead to gaps. MongoDB does not require a special sequence object. A collection can be used thanks to incremental update ($inc) and returning the updated value in a single atomic operation with findOneAndUpdate().

Here is an example. I create a "sequence" collection to hold sequence numbers and a "demo" collection to insert values with an auto incremented identifier:

db.createCollection("demo");
db.createCollection("sequence");

An insert can simply fetch the next value while incrementing it:

db.demo.insertOne({
 _id: db.sequences.findOneAndUpdate(         
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'm the first"
});

db.demo.find();

[ { _id: { _id: 'demo_id', seq: 1 }, value: "I'm the first" } ]

I start two transactions:

sessionA = db.getMongo().startSession();
sessionA.startTransaction();
dbA = sessionA.getDatabase(db.getName());

sessionB = db.getMongo().startSession();
sessionB.startTransaction();
dbB = sessionB.getDatabase(db.getName());

Scalable sequence (accepting gaps on rollback)

The two transactions insert a document into "demo" with an "_id" fetched from the "sequences":

dbA.demo.insertOne({
 _id: db.sequences.findOneAndUpdate(         // non-transactional
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll abort"
});

dbB.demo.insertOne({
 _id: db.sequences.findOneAndUpdate(         // non-transactional
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll commit"
});

It is important to note that I increment ($inc) and fetch the value (returnDocument: "after") with db, out of the dbA or dbB transactions. The sequence operation is atomic, but non-transactional (not part of a multi-document transaction). This simulates the behavior of sequences in SQL databases.

The first transaction aborts (rollback) and the second one commits:

sessionA.abortTransaction();
sessionA.endSession();

sessionB.commitTransaction();
sessionB.endSession();

I check the result:

db.demo.find()

[
  { _id: { _id: 'demo_id', seq: 1 }, value: "I'm the first" },
  { _id: { _id: 'demo_id', seq: 3 }, value: "I'll commit" }
]

I have a gap in the numbers because "_id: 1" has been used by a transaction that aborted. The transaction has been rolled back, but because I incremented the sequence out of the transaction (using db instead of dbA) the incrementat was not rolled back.

Note that all updates to a single document are atomic, but I used findOneAndUpdate() so that it returns the updated document in the same atomic operation that updated it. It can return the before or after value and I used returnDocument: "after" to get the next value. I used upsert: true to initialize the sequence if no value exists, and $inc sets the field to the specified value when it doesn't exist.

No-gap Sequences (and optimistic locking)

If you want a no-gap sequence, you can fetch the sequence number in the multi-document transaction:

sessionA = db.getMongo().startSession();
sessionA.startTransaction();
dbA = sessionA.getDatabase(db.getName());

sessionB = db.getMongo().startSession();
sessionB.startTransaction();
dbB = sessionB.getDatabase(db.getName());

dbA.demo.insertOne({
 _id: dbA.sequences.findOneAndUpdate(      // part of the transaction
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll abort"
});

dbB.demo.insertOne({
 _id: dbB.sequences.findOneAndUpdate(      // part of the transaction
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll commit"
});

When two transactions try to increment the same sequence, an optimistic locking error is raised:

MongoServerError[WriteConflict]: Caused by :: Write conflict during plan execution and yielding is disabled. :: Please retry your operation or multi-document transaction.

This is a retriable error and the application should have implemented a retry logic:

sessionA.abortTransaction();


// retry the insert
sessionB.abortTransaction();
sessionB.startTransaction();
dbB.demo.insertOne({
 _id: dbB.sequences.findOneAndUpdate(      // part of the transaction
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll commit"
});

sessionB.commitTransaction();
sessionB.endSession();
sessionA.endSession();

I check the result:

db.demo.find()

[
  { _id: { _id: 'demo_id', seq: 1 }, value: "I'm the first" },
  { _id: { _id: 'demo_id', seq: 3 }, value: "I'll commit" },
  { _id: { _id: 'demo_id', seq: 4 }, value: "I'll commit" }
]

Here, the first session rollback didn't introduce another gap because the sequence increment was part of the insert transaction. To achieve the same in a SQL database, you must use a table and UPDATE ... SET seq=seq+1 RETURNING seq;. With pessimistic locking, it acquires a lock and waits for the other transaction to complete. To be scalable, SQL databases provide a non-transactional SEQUENCE that does the same without waiting, but with gaps. It still has some scalability issues, and distributed databases may discourage (CockroachDB raises a warning) or even not support sequences (like Google Spanner or Amazon Aurora DSQL).

Incrementing identifiers for the primary key

MongoDB provides developers with greater control, allowing them to apply the same logic to a collection while deciding whether to include it in a transaction. It also supports optimized atomic operations. You can also use Atlas triggers to deploy the logic into the managed database, like demonstrated in MongoDB Auto-Increment

It's important to note that generating an incremented sequence is typically rare, primarily occurring during migrations from MySQL's AUTO_INCREMENT or PostgreSQL's BIGSERIAL. The default "_id" field is a globally unique and scalable ObjectId. You can also use a UUID generated by the application and choose the format (UUIDv4 or UUIDv7) to distribute or collocate the documents inserted at the same time.

In a previous post about No-gap sequence in PostgreSQL and YugabyteDB, I mentioned that sequences in SQL databases are not transactional, which can lead to gaps. MongoDB does not require a special sequence object. A collection can be used thanks to incremental update ($inc) and returning the updated value in a single atomic operation with findOneAndUpdate().

Here is an example. I create a "sequence" collection to hold sequence numbers and a "demo" collection to insert values with an auto incremented identifier:

db.createCollection("demo");
db.createCollection("sequence");

An insert can simply fetch the next value while incrementing it:

db.demo.insertOne({
 _id: db.sequences.findOneAndUpdate(         
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'm the first"
});

db.demo.find();

[ { _id: { _id: 'demo_id', seq: 1 }, value: "I'm the first" } ]

I start two transactions:

sessionA = db.getMongo().startSession();
sessionA.startTransaction();
dbA = sessionA.getDatabase(db.getName());

sessionB = db.getMongo().startSession();
sessionB.startTransaction();
dbB = sessionB.getDatabase(db.getName());

Scalable sequence (accepting gaps on rollback)

The two transactions insert a document into "demo" with an "_id" fetched from the "sequences":

dbA.demo.insertOne({
 _id: db.sequences.findOneAndUpdate(         // non-transactional
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll abort"
});

dbB.demo.insertOne({
 _id: db.sequences.findOneAndUpdate(         // non-transactional
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll commit"
});

It is important to note that I increment ($inc) and fetch the value (returnDocument: "after") with db, out of the dbA or dbB transactions. The sequence operation is atomic, but non-transactional (not part of a multi-document transaction). This simulates the behavior of sequences in SQL databases.

The first transaction aborts (rollback) and the second one commits:

sessionA.abortTransaction();
sessionA.endSession();

sessionB.commitTransaction();
sessionB.endSession();

I check the result:

db.demo.find()

[
  { _id: { _id: 'demo_id', seq: 1 }, value: "I'm the first" },
  { _id: { _id: 'demo_id', seq: 3 }, value: "I'll commit" }
]

I have a gap in the numbers because {_id: 2} has been used by a transaction that aborted. The transaction has been rolled back, but because I incremented the sequence out of the transaction (using db instead of dbA) the increment was not rolled back.

Note that all updates to a single document are atomic, but I used findOneAndUpdate() so that it returns the updated document in the same atomic operation that updated it. It can return the before or after value and I used returnDocument: "after" to get the next value. I used upsert: true to initialize the sequence if no value exists, and $inc sets the field to the specified value when it doesn't exist.

No-gap Sequences (and optimistic locking)

If you want a no-gap sequence, you can fetch the sequence number in the multi-document transaction:

sessionA = db.getMongo().startSession();
sessionA.startTransaction();
dbA = sessionA.getDatabase(db.getName());

sessionB = db.getMongo().startSession();
sessionB.startTransaction();
dbB = sessionB.getDatabase(db.getName());

dbA.demo.insertOne({
 _id: dbA.sequences.findOneAndUpdate(      // part of the transaction
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll abort"
});

dbB.demo.insertOne({
 _id: dbB.sequences.findOneAndUpdate(      // part of the transaction
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll commit"
});

When two transactions try to increment the same sequence, an optimistic locking error is raised:

MongoServerError[WriteConflict]: Caused by :: Write conflict during plan execution and yielding is disabled. :: Please retry your operation or multi-document transaction.

This is a retriable error and the application should have implemented a retry logic:

sessionA.abortTransaction();


// retry the insert
sessionB.abortTransaction();
sessionB.startTransaction();
dbB.demo.insertOne({
 _id: dbB.sequences.findOneAndUpdate(      // part of the transaction
  { _id: "demo_id" },
  { $inc: { seq: 1 } },
  { upsert: true, returnDocument: "after" }
),
 value: "I'll commit"
});

sessionB.commitTransaction();
sessionB.endSession();
sessionA.endSession();

I check the result:

db.demo.find()

[
  { _id: { _id: 'demo_id', seq: 1 }, value: "I'm the first" },
  { _id: { _id: 'demo_id', seq: 3 }, value: "I'll commit" },
  { _id: { _id: 'demo_id', seq: 4 }, value: "I'll commit" }
]

Here, the first session rollback didn't introduce another gap because the sequence increment was part of the insert transaction. To achieve the same in a SQL database, you must use a table and UPDATE ... SET seq=seq+1 RETURNING seq;. With pessimistic locking, it acquires a lock and waits for the other transaction to complete. To be scalable, SQL databases provide a non-transactional SEQUENCE that does the same without waiting, but with gaps. It still has some scalability issues, and distributed databases may discourage (CockroachDB raises a warning) or even not support sequences (like Google Spanner or Amazon Aurora DSQL).

Incrementing identifiers for the primary key

MongoDB provides developers with greater control, allowing them to apply the same logic to a collection while deciding whether to include it in a transaction. It also supports optimized atomic operations. You can also use Atlas triggers to deploy the logic into the managed database, like demonstrated in MongoDB Auto-Increment

It's important to note that generating an incremented sequence is typically rare, primarily occurring during migrations from MySQL's AUTO_INCREMENT or PostgreSQL's BIGSERIAL. The default "_id" field is a globally unique and scalable ObjectId. You can also use a UUID generated by the application and choose the format (UUIDv4 or UUIDv7) to distribute or collocate the documents inserted at the same time.