<!-- llms-explorer concept facts · https://llms-explorer.com/tree/side-writes-table-and-hybrid-index-builds/ · pack 2026-10-31 · ~1452 tokens -->

# Side-writes table and hybrid index builds

> Source-anchored research for Side-writes table and hybrid index builds. Run status: COMPLETED.

Parent: [Resumable index builds](https://llms-explorer.com/tree/resumable-index-builds/) · 3 facets · 14 facts · page: https://llms-explorer.com/tree/side-writes-table-and-hybrid-index-builds/

## How it works

- In the MongoDB 8.0 process, an S collection lock blocks writes while remaining side writes are drained. A later X lock blocks reads and writes for final draining, constraint checks and commit. These phases are typically brief, but their duration depends on the remaining side writes. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/core/index-creation/)
- Rebuilding an index under heavy write load can reduce write throughput and prolong the build. MongoDB recommends a window with reduced writes; the side-write mechanism does not promise disruption-free rebuilding. (medium confidence) — [source](https://www.mongodb.com/docs/v8.0/core/index-creation/)
- [redacted] records a drain-status hang without concurrent collection writes; the community thread reports other conditions with similar status text. The message alone does not establish a growing side-write backlog or a unique root cause. (medium confidence) — [source](https://www.mongodb.com/community/forums/t/index-build-draining-writes-received-during-build/127924)

## Comparisons and alternatives

- In simultaneous replica-set builds, nodes continue buffering and periodically draining side writes while awaiting the commit decision. Waiting at this stage can reflect commit coordination rather than unfinished collection scanning. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md)

## Facts and statements

- Hybrid index builds, introduced in MongoDB 4.2, combine a collection scan and sorted bulk loading with interception of concurrent writes into an internal storage-engine table. The 8.0 manual describes the corresponding temporary side-writes table and external-sorter stages. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md)
- In the hybrid path, inserts, updates and deletes still modify the collection. Their index-key changes are buffered for the index under construction from before scanning until completion; an update from a=1 to a=2 records deletion of key 1 and insertion of key 2. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md)
- The side-writes table drains in insertion order. An initial drain allows ongoing writes, so later drains must apply changes that arrived afterward; the table is removed only after remaining changes are applied. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md)
- A unique hybrid index build can temporarily encounter duplicate keys while writes continue. The build rechecks duplicates before committing and fails if violations persist; accepting writes during construction does not establish that the new unique index will succeed. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md)
- Xu Jing's production case describes MongoDB 4.2 writes stalling during bulk loading: an index builder's IX lock blocked a monitoring profile:-1 command requesting a database R lock, and queued writes then waited behind that request. This is a historical lock-queue interaction, not evidence that all hybrid builds block writes for their full duration. (low confidence) — [source](https://developer.cloud.tencent.com/article/2080304?from=15425&frompage=seopage)
- SERVER-130777 reports that an array-producing side write after scanning, followed by clean shutdown before commit, can lose in-memory multikey metadata on resume and produce incorrect query results. Its 2026-10-12 update lists affected versions 6.0.0, 7.0.0 and 8.0.0, with no fix version; this is a ticket report, not a verified patch-release matrix. (low confidence) (verified as of 2026-10-12) — [source](https://jira.mongodb.org/browse/SERVER-130777)
- Percona's instrumented example includes drained-side-write log fields numApplied, totalInserted, totalDeleted and durationMillis. These describe drain activity; the same walkthrough shows commit-quorum messages as a separate step. (low confidence) — [source](https://www.percona.com/blog/stages-of-index-build-in-mongodb/)
- For MongoDB 8.0, heavy writes during an index build can reduce write performance and extend build time. The manual recommends considering a maintenance window with stopped or reduced application writes; allowing concurrent writes does not guarantee negligible operational impact. (low confidence) — [source](https://www.mongodb.com/docs/v8.0/core/index-creation/)
- Xu Jing reports a historical MongoDB 4.2 incident in which writes stopped for roughly five minutes during bulk loading. The investigation attributed the outage to a monitoring profile:-1 command waiting for a database shared lock behind the build, with subsequent writes queued behind that request. This is a version-scoped production report, not proof of the same behavior in current releases. (low confidence) — [source](https://developer.cloud.tencent.com/article/2080304?from=15425&frompage=seopage)
- The message "Index Build: draining writes received during build" does not by itself establish a heavy side-write backlog. [redacted] reports it on MongoDB 4.4.0 with four documents and no concurrent application activity; the ticket links a self-connectivity issue. Diagnose logs and replica-set coordination before attributing the message to write volume. (medium confidence) — source: `archived:private-reference`
