MongoDB 8.0 Introduces 30-47% Write Performance Improvement and 5-Year Long-Term Support

MongoDB 8.0 focuses on performance and stability improvements, significantly enhancing write performance and query performance. In particular, write throughput improved by 30-47% due to changes in the write durability guarantee method, and average throughput improved by more than 45% with the introduction of Express Plan, which eliminates query planning overhead for single-record lookups.

Long-Term Support and Release Policy Changes

MongoDB 8.0 is effectively a Long-Term Support (LTS) version supported for approximately 5 years from its launch in October 2024 through October 2029. Compared to the previous 3-year support period, this allows for reduced upgrade resources. Starting from version 8.2, new features can be flexibly introduced via minor releases even in on-premises environments.

Performance Improvements: Write Concern and Express Plan

The criteria for Write Concern 'majority' were changed from lastAppliedOpTime to lastWrittenOpTime, eliminating the wait for data file application. This resulted in a 30-47% improvement in write throughput, with larger batch sizes yielding greater improvements. However, it is recommended to use causal consistency sessions to account for the possibility that the latest data may not be reflected when querying secondaries immediately after a write.

Express Plan eliminates query planning overhead for lookups by the _id field or single-record lookups based on unique indexes. Benchmark results confirmed an average throughput improvement of more than 45% and a response time reduction of approximately 30%.

Architecture and Operational Efficiency

• Bulk Write Improvements: Introduction of the bulkWrite command for multiple collections and batch processing of oplog entries reduce replication lag.
• Config Shard: Config servers operate like regular shard nodes, reducing operational complexity and costs for small clusters.
• PBWM Lock Removal: The Parallel Batch Writer Mode lock, which caused read latency on secondary nodes, has been completely removed, improving read performance.

Precautions

In sharded clusters, if _id is not the shard key, updates using _id conditions may update documents across all shards; therefore, queries should include the shard key.