ApsaraDB for MongoDB:Overview of new features in MongoDB 5.0

Native time series platform

MongoDB 5.0 adds first-class support for time series data across its full lifecycle: ingestion, storage, query, real-time analysis, visualization, online archival, and expiration.

Time series collections store data in a compressed, columnar-optimized format that reduces storage size and I/O. Unlike a dedicated time series database, time series collections coexist with regular collections in the same database, so you can query time series and transactional data together without a separate integration layer.

To create a time series collection, run:

db.createCollection("collection_name", { timeseries: { timeField: "timestamp" } })

MongoDB automatically partitions data into time-based chunks, handles out-of-order writes, and creates a clustered index sorted by time to minimize query latency.

Kafka integration. The MongoDB Connector for Apache Kafka supports time series collections natively. Write directly from Kafka topic messages into a time series collection, with processing and aggregation happening at ingestion time.

Analytical queries. The MongoDB Query API extends window functions to support time-based windows. In addition to row-based aggregations (such as three-row moving averages), windows can be defined in time units—for example, a 15-minute exponential moving average (EMA), derivative, or integral. New time operators include $dateAdd, $dateSubstract, $dateDiff, and $dateTrunc for custom time window queries. Window functions work on both time series and regular collections.

Applicable workloads: IoT telemetry, financial analysis, logistics tracking.

Live resharding

Resharding in earlier MongoDB versions required either dumping and reloading entire collections offline—a process that could take days for collections larger than 10 TB on a three-shard cluster—or manually coordinating migration between two sharded clusters. One MongoDB user spent three months migrating 10 billion documents using the manual approach.

MongoDB 5.0 resharding is fully online and automated.

How it works. Running reshardCollection triggers a background process with three phases:

1. Clone: Each recipient shard clones the collection data using the new shard key.

2. Apply: Recipient shards apply ongoing write operations from the oplog to stay current with the source.

3. Switch: MongoDB switches to the new collection and deletes the old one.

The command syntax is:

reshardCollection: "<database>.<collection>", key: <shardkey>

The resharding window shrinks from weeks or months to minutes or hours, with no downtime required. Use a development or test environment to evaluate different shard keys before running resharding in production. You can also modify the shard keys as your workload grows or evolves.

Versioned API

Without a declared API version, a server upgrade can change command behavior and break your application. The Versioned API defines a set of commands and parameters that are most commonly used in applications. These commands remain stable across all MongoDB releases—both annual major releases and quarterly rapid releases—decoupling the application lifecycle from the database lifecycle. You can pin the driver to a specific API version, and your application can continue running after a server upgrade for years without code changes.

Running a new API version alongside an existing one on the same server is also supported, enabling incremental migration.

Default majority write concern

Starting from MongoDB 5.0, the default Write Concern is majority. A write is acknowledged only after it is applied to the primary node and persisted to the logs of a majority of secondary nodes.

This provides stronger data durability out of the box compared to earlier defaults. Write Concern remains fully tunable—adjust it to balance write latency against durability requirements.

Connection management improvements

MongoDB uses one thread per client connection (net.serviceExecutor = synchronous). Under high concurrency, thread creation and context-switching consume significant resources. When connections grow uncontrolled—a situation known as a connection storm—the server can become overloaded, often at exactly the moment load is already high.

MongoDB 5.0 addresses this with three driver-level improvements:

• Connection limiting: The driver caps the number of connections it attempts to create, protecting the server from being overwhelmed.

• Reduced health-check frequency: The driver checks connection pools less often, giving unresponsive or overloaded nodes time to buffer and recover.

• Healthiest-pool routing: Instead of selecting a server at random, the driver routes to the server with the healthiest connection pool.

These changes complement earlier improvements to mongos query routing, further increasing throughput under high concurrency.

Long-running snapshot queries

Long-running snapshot queries improve the versatility and flexibility of applications. By default, snapshot queries executed by this feature have a duration of 5 minutes. The execution duration is customizable. This feature maintains strong consistency with snapshot isolation guarantees without affecting the performance of your live and transactional workloads, and allows you to execute snapshot queries on secondary nodes—letting you isolate analytical workloads from your primary.

How it works. Snapshot queries rely on Durable history, a storage engine feature available since MongoDB 4.4. Durable history maintains a snapshot of changed field values from the start of a query. Under high write load, this also alleviates caching pressure in the storage engine and improves query throughput.

New MongoDB Shell

The MongoDB Shell has been redesigned as a modern command-line environment built on Node.js REPL. It is now the default shell for MongoDB.

Developer experience improvements:

• Syntax highlighting: Distinguishes fields, values, and data types to reduce syntax errors.

• Intelligent auto-complete: Suggests methods, commands, and MQL expressions based on your MongoDB version.

• Contextual error messages: Pinpoints the location of an error and suggests corrections.

If you forget a command's syntax, search for it directly in the shell:

Scripting: Scripts run on the Node.js REPL, giving you access to all Node.js APIs and npm packages. Load and run scripts from the file system using load() and eval(), the same as in previous shell versions.

Snippets: Install the Snippets plugin to extend the shell with reusable scripts that use Node.js APIs and npm packages. Snippets can be automatically loaded to the MongoDB Shell. MongoDB maintains a Snippets repository that provides features such as analyzing plug-ins for specified collection patterns.

Snippets are an experimental feature.

PyMongoArrow

PyMongoArrow is a new Python library that converts MongoDB query results directly into Pandas DataFrames and NumPy arrays. Use it to run machine learning workflows and analytical tasks on MongoDB data without manual data transformation.

Schema validation improvements

When a write operation fails schema validation in MongoDB 5.0, the error message identifies the specific document and field that violates the collection's validation rules. This makes it faster to locate and fix the code path responsible for invalid writes.

Resumable index builds

If a node restarts while an index build is in progress, MongoDB 5.0 automatically resumes the build from where it stopped. Index builds on large collections are no longer at risk of restarting from scratch during planned maintenance, upgrades, or rolling restarts.

Release cadence

Starting with MongoDB 5.0, MongoDB ships in two series:

The two-series model lets MongoDB deliver new features faster. Each version must be verified on more than 20 supported platforms, so decoupling rapid iteration from production releases keeps the delivery pipeline moving.

What's next

For a complete list of changes in MongoDB 5.0, see the Release notes for MongoDB 5.0.