Is managed MongoDB the right database for your analytics workload?

The announcement of DuckDB v2.0, previewed in August 2026 and scheduled for release in September 2026, has sharpened a debate that many infrastructure teams have quietly been having for a while: are we using the right database for analytics, or just the one we already had running? MongoDB is a legitimate choice for a wide range of workloads, but analytics is where the answer gets complicated. Here is an honest account of where a managed document store earns its place, and where a purpose-built engine will leave it behind.

What MongoDB is actually built for

MongoDB stores data in BSON, a binary JSON format, and its query engine was designed around retrieving specific documents or subsets of a collection. That design is genuinely excellent for operational workloads: flexible schemas, horizontal scaling, fast point lookups, and the ability to evolve a data model without painful migrations. For applications that write frequently and read selectively, MongoDB’s architecture is a strong fit.

The aggregation pipeline extends MongoDB into analytical territory, and for light to medium complexity it works well. But the constraints are real and documented. Pipeline stages are limited to 100 MB of RAM before MongoDB either errors or spills to disk, at which point latency increases by orders of magnitude. The $lookup operator mimics joins, but at millions of documents it becomes slow and memory-heavy. Map-reduce was deprecated in MongoDB 5.0. The pipeline limit sits at 1,000 stages. These are not edge cases; they are the boundaries of a system designed for document retrieval, not large-scale aggregation.

MongoDB 8.0 did introduce meaningful improvements for one specific analytics pattern: time series. Block Processing for Time Series Collections applies a columnar execution model to aggregation stages like $match, $group, and $setWindowFields, processing blocks of data rather than one document at a time. Compression rates of 70 to 90 percent on raw time series data are a genuine operational win. If your analytics workload is primarily time series, MongoDB 8.0 closes a real gap.

Where MongoDB analytics breaks down at scale

The pattern that causes the most pain is the one that looks innocent at first: a reporting dashboard or analytics API built directly on top of an operational MongoDB collection. At small scale, it works fine. As data grows, collection scans appear because indexes do not cover the aggregation shape, $unwind on large arrays becomes expensive, and memory pressure on the aggregation stages starts producing errors or forcing disk spills. The fix is usually to push the aggregation to a read replica and tune stage ordering carefully, but this is engineering effort applied to a problem that a columnar engine would not have in the first place.

The aggregation pipeline is a capable tool for operational reporting. It is not an OLAP engine, and treating it as one will eventually cost you more in tuning time than a purpose-built solution would have cost to set up.

The distinction matters because the two query patterns are structurally different. OLAP queries scan large portions of a dataset, filter on multiple dimensions, and aggregate across millions of rows. Document stores are optimised for retrieving a small number of documents quickly. MongoDB’s columnar improvements in time series are a step toward bridging that gap, but they apply to a specific collection type, not to general aggregation across arbitrary document collections.

What DuckDB v2.0 signals about the direction of analytics

DuckDB is an embedded, column-oriented RDBMS built for high-performance OLAP queries. Its vectorized engine processes data in chunks of 256 tuples using SIMD instructions, which means complex aggregations across large datasets run fast without a separate server process. Version 1.0 shipped in June 2024; the 1.x line has since introduced LTS releases, a native VARIANT type for semi-structured data, and steady performance improvements.

The planned v2.0 release, previewed by the DuckDB team in August 2026, is not a cosmetic version bump. It ships a new SQL parser, a new default storage format, a reworked C API, and what the team has described as the beginning of “the year of DuckDB as a server.” That framing matters: DuckDB has historically been an embedded, single-process tool. The v2.0 direction signals that the project is moving toward use cases that look more like a lightweight analytics server, not just a library you embed in a Python script.

The practical consequence for teams running MongoDB for analytics is that the alternative is getting easier to operate, not harder. A lean embedded OLAP engine that can query Parquet files, JSON, and now semi-structured VARIANT data directly is a credible replacement for a MongoDB aggregation pipeline that has been stretched beyond its natural use case.

The managed MongoDB case that still holds

None of this means MongoDB is the wrong choice. It means analytics-only is the wrong use case to anchor on. The situations where managed MongoDB genuinely earns its place are mixed workloads: applications that write operational data continuously and need analytics on recent subsets of that data, without the overhead of a separate ETL pipeline into a warehouse. For those workloads, the read replica pattern, combined with MongoDB’s secondary indexes and the time series block processing improvements in 8.0, delivers real value.

The other strong case is schema flexibility at ingestion time. When upstream data sources are heterogeneous and evolving, a document store absorbs that variability without schema migrations. If your analytics queries are then scoped to recent data or to specific document subsets, MongoDB’s aggregation pipeline is fast enough and operationally simpler than maintaining a separate columnar store.

We run managed MongoDB across our European infrastructure, and the workloads where it performs reliably are exactly these: operational data with real-time reporting on recent windows, not full-table analytical scans. Our 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at every site, mean that applications pulling from MongoDB alongside hyperscaler services do not pay a latency penalty for the round trip. That matters when you are building a reporting API that aggregates from MongoDB and enriches from a cloud data service in the same request path.

Making the call: a practical decision tree

• Your queries scan millions of documents and aggregate across many dimensions: MongoDB will struggle. A columnar engine like DuckDB, ClickHouse, or a managed data warehouse is the right tool.
• Your analytics is on recent data from an operational MongoDB collection: Read replicas and careful pipeline tuning will work. Managed MongoDB is a reasonable choice.
• Your data is time series with high ingestion rates: MongoDB 8.0 Time Series Collections with Block Processing are now a legitimate option alongside purpose-built time series databases.
• You need schema flexibility at ingestion and light analytics on top: MongoDB’s document model earns its place. Do not add a warehouse until the aggregation pipeline becomes the bottleneck.
• You are running both operational and analytical queries on the same collection at scale: Separate the concerns. Use MongoDB for writes and operational reads; export to a columnar store for analytics.

The mistake most teams make is not choosing MongoDB incorrectly at the start. It is not revisiting the decision as data volume grows. The aggregation pipeline that handled reporting at 10 million documents will not handle it the same way at 500 million, and the time to architect a separation is before the first production incident, not after.