A vectored insert is when one WriteUnitOfWork (transaction) performs multiple document inserts before committing. This mechanism is used on primaries for bulk writes and secondaries during oplog application.

A typical insert executes in the order of:

1. Insert new document into the record store.
2. For each index, calculate the document's index key and update the index.

A vectored insert instead works as:

1. Insert document A into the record store.
2. Insert document B into the record store.
3. Calculate and update indexes for A.
4. Calculate and update indexes for B.

Performing the same actions but adding in timestamps:

1. Set the timestamp to T(A).
2. Insert document A into the record store (gets T(A)).
3. Set the timestamp to T(B).
4. Insert document B into the record store (gets T(B)).
5. Update indexes for A (gets T(B)).
6. Update indexes for B (gets T(B)).

Scanning the collection at T(A) will show document A, but searching for A via an index will not succeed.

Secondaries are currently immune to observing this anomaly; read timestamps on a secondary (e.g: majority reads) must take place on a batch boundary. This was intended to ensure that unique indexes could not be observed in a temporarily inconsistent state.