Sending one operation per round trip is slow when you have many writes. bulkWrite batches operations into a single request, which cuts network overhead and can parallelize on the server, but its ordered and unordered modes have different failure behavior.
Before you start
You should be comfortable with the Node.js driver and basic write operations. This article uses bulkWrite with mixed operations.
Step-by-step walkthrough
Step 1: Batch related operations
Collect inserts, updates, replaces and deletes into one array and send them together. The driver groups them by type internally, so a single call handles a mixed batch and the round trips drop from one-per-operation to one per batch.
Step 2: Choose ordered or unordered
ordered: true (the default) stops at the first error and leaves later operations unapplied. ordered: false continues past failures and can run operations in parallel, which is faster. Use unordered when operations are independent, and ordered when a later operation depends on an earlier one.
Step 3: Inspect the result for partial failures
The result reports insertedCount, modifiedCount and, critically, writeErrors, because an unordered batch can partly succeed. Ignoring writeErrors hides failed documents, so check the counts and handle the errors, often by retrying only the failed items.
Worked scenario
An unordered batch applies independent operations and reports errors.
const result = await db.collection('inventory').bulkWrite(
[
{ insertOne: { document: { _id: 1, qty: 10 } } },
{ updateOne: { filter: { _id: 2 }, update: { $inc: { qty: 1 } } } },
{ deleteOne: { filter: { _id: 3 } } },
],
{ ordered: false }
);
console.log(result.insertedCount, result.modifiedCount, result.deletedCount);Walk through the example
The three operations run in one request, and with ordered: false a failure on one does not stop the others. The result carries per-type counts so the caller can confirm what applied. If writeErrors is non-empty, the caller knows some documents failed and can retry them.
Common mistake
Using the default ordered mode for a large independent batch, which stops at the first conflict and wastes the rest of the work. Another is not checking writeErrors, so partial failures go unnoticed.
Verify the behavior
Send a batch with one invalid operation and confirm ordered mode stops while unordered continues. Assert the counts match the operations that applied. Confirm writeErrors lists the failed items so they can be retried.
Interview exercise
When do you need ordered bulk writes?
Answer and reasoning
When operations depend on each other, such as inserting a document and then updating it in the same batch, because stopping on the first error preserves the sequence. For independent operations, unordered is faster and more resilient. The dependency, not the size, decides the mode.
Continue learning
Compare write tuning in Write concern and indexing in Compound indexes. Read the MongoDB bulkWrite documentation and try the MongoDB interview questions.