Bulk Writes

Bulk Writes

Bulk Writes and Write Acknowledgment

bulkWrite sends a mixed list of inserts, updates, replacements and deletes as one command. The win is round trips: a thousand updateOne calls pay a thousand network latencies, one bulkWrite pays one.

Four different operations in one command (Node driver 7.6.0)JavaScript

const res = await col.bulkWrite([
  { insertOne: { document: { sku: "C3", qty: 1 } } },
  { updateOne: { filter: { sku: "B2" }, update: { $inc: { qty: 2 } } } },
  { updateOne: { filter: { sku: "D4" }, update: { $set: { qty: 4 } }, upsert: true } },
  { deleteOne: { filter: { sku: "C3" } } }
], { ordered: false });
console.log(res.insertedCount, res.matchedCount, res.modifiedCount, res.deletedCount,
  res.upsertedCount, res.upsertedIds);

Output

1 1 1 1 1 { '2': new ObjectId('6ab1caf87b740c892da76fd1') }

The keys of upsertedIds and insertedIds are the positions in the array you sent — here '2', the third operation — which is how you match generated ids back to your input. ordered behaves as for insertMany: ordered stops at the first failure, unordered runs everything and collects the errors into a MongoBulkWriteError whose result carries these counts.

Write concern decides when the server answers. w: 1 (the default) means the primary applied the write in memory; j: true adds "and flushed it to the journal"; w: "majority" waits for a majority of replica set members, which makes a write survive a failover; w: 0 asks for no reply.

Three write concerns against a standalone serverJavaScript

const a = await wc.insertOne({ n: 1 }, { writeConcern: { w: 0 } });
console.log('w:0        ->', a.acknowledged, a.insertedId);
const b = await wc.insertOne({ n: 2 }, { writeConcern: { w: 1, j: true } });
console.log('w:1 j:true ->', b.acknowledged);
try {
  await wc.insertOne({ n: 3 }, { writeConcern: { w: 2, wtimeoutMS: 500 } });
} catch (e) { console.log('w:2        ->', e.code, e.errmsg ?? e.message); }

Output

w:0        -> false new ObjectId('6ab1caf88590cbbfc0da77a4')
w:1 j:true -> true
w:2        -> 2 cannot use 'w' > 1 when a host is not replicated

Three lessons in six lines. With w: 0 the driver still invents the _id locally but acknowledged is false, so a duplicate key error or a full disk never reaches your code. w: 2 is not portable: a standalone server rejects it, so replica-set code fails the moment someone runs it against a laptop mongod. And wtimeoutMS limits only the waiting — if it expires the write may still have been applied, so write timeouts are unsafe to retry blindly unless the operation is idempotent.

MENU