Why Enterprises Choose MongoDB Part 3 — Technical Reasons In Depth
The outcomes from Part 2 — Wells Fargo, McKesson, Victoria's Secret, and others — have concrete technical explanations. This post examines why the document model reduces the overhead of relational normalisation, how sharding-based horizontal scaling handles unpredictable growth, how multi-document ACID transactions earned trust in finance and healthcare, and how Atlas Vector Search simplifies AI application architecture. MongoDB 8.x benchmark numbers, the security and compliance stack, and developer experience (DX) improvements are covered from an engineering perspective.
Series outline
- Part 1 — From NoSQL Underdog to Enterprise Standard (previous post)
- Part 2 — Industry Case Studies In Depth (previous post)
- Part 3 — Technical Reasons Enterprises Choose MongoDB (this post)
- Part 4 — Escape Legacy: Migrating from RDBMS to MongoDB (coming soon)
Table of Contents
- Introduction — "It's good" — but why, exactly?
- Technical reason ① The document model — tearing down the relational wall
- Technical reason ② Horizontal scaling (sharding) — handling unpredictable growth
- Technical reason ③ ACID transactions — ending the "NoSQL can't do finance" myth
- Technical reason ④ Atlas Vector Search — the core weapon for the AI era
- Technical reason ⑤ MongoDB 8.x — the fastest release ever built
- Technical reason ⑥ Security and compliance — why enterprises trust it
- Technical reason ⑦ Developer experience (DX) — speed as competitive advantage
- Side-by-side comparison: MongoDB vs relational databases
- Part 3 wrap-up and what's next
1. Introduction — "It's good" — but why, exactly?
Part 2 showed that organisations like Wells Fargo, McKesson, and Victoria's Secret achieved dramatic results with MongoDB. But the "how" story was left untold.
Every outcome has a technical explanation. What makes it different from a relational database? Why is it better suited to the AI era? What changed in the most recent versions? This post takes an engineering lens to MongoDB's core technology and unpacks each piece.
2. Technical reason ① The document model — tearing down the relational wall
The root problem with relational databases: the normalisation tax
Relational databases were designed around normalisation principles from the 1970s. The idea was to eliminate data duplication by splitting information across many tables.
Consider a single insurance policy. In a relational database, that data fragments across a contracts table, a coverage-items table, an insured-parties table, a payments table — potentially dozens of tables in total. Rendering that data on screen requires dozens of JOIN operations every time, and modifying it means splitting and re-assembling the pieces again. This is not merely complex — it is a direct hit on runtime performance.
MongoDB's document model: data stored the way it lives
MongoDB stores data as BSON (Binary JSON) documents. That same insurance policy sits in a single document with nested sub-documents. A query retrieves everything in one read, with no JOINs.
{
"_id": "order_001",
"customer": {
"name": "Jane Smith",
"email": "jane@example.com"
},
"items": [
{ "product": "Laptop", "price": 1500, "qty": 1 },
{ "product": "Mouse", "price": 35, "qty": 2 }
],
"status": "shipped",
"createdAt": "2026-04-12T09:00:00Z"
}
In a relational database, retrieving this view would require joining at least four tables: customers, orders, order_items, and products.
The practical value of flexible schema
Adding a column to a relational database requires an ALTER TABLE migration. On a table with hundreds of millions of rows, that migration can cause hours of downtime.
In MongoDB, adding a new field is immediate. Existing documents remain untouched; only new documents include the new field. Schema Validation is available when strict structure needs to be enforced.
What does that flexibility translate to in practice? Teams that have migrated from relational databases to MongoDB consistently report development cycle reductions of 30–50%.
3. Technical reason ② Horizontal scaling (sharding) — handling unpredictable growth
The ceiling on vertical scaling
The traditional relational scaling strategy is vertical — attach a faster CPU and more RAM to the server. This is straightforward but runs into two problems quickly: cost grows exponentially, and physical limits exist.
MongoDB's sharding: distribute data, distribute load
MongoDB's design philosophy centres on horizontal scaling (scale-out) through sharding. Data is distributed across multiple servers (shards) and traffic is processed in parallel. In principle, the system scales without bound simply by adding shards.
MongoDB 8.0 delivered sharding improvements that made data distribution across shards up to 50 times faster than before, while cutting the overhead of initiating sharding by up to 50%.
Proven in production
As Part 2 showed, 99Minutos sustained 7,500% growth in under two years because MongoDB sharding kept the system running. McKesson absorbed a 300x increase in transaction volume in just six months. Neither scale-out was achievable with vertical scaling.
4. Technical reason ③ ACID transactions — ending the "NoSQL can't do finance" myth
What ACID means
ACID describes four properties required for safe database transactions.
| Property | Meaning |
|---|---|
| Atomicity | All operations in a transaction succeed together or all fail together |
| Consistency | Data always remains in a valid state before and after a transaction |
| Isolation | Concurrent transactions do not interfere with each other |
| Durability | Committed transactions survive failures permanently |
In a bank transfer, the debit from account A and the credit to account B must either both succeed or both fail. If only one completes, the data is corrupted.
MongoDB's ACID journey: the 2018 turning point
Early MongoDB guaranteed atomicity only at the single-document level. Multi-document transactions spanning multiple collections were not supported — and that was the single biggest barrier to enterprise adoption in financial services and healthcare.
MongoDB 4.0 in 2018 changed everything. Multi-document ACID transactions became officially supported, and subsequent releases extended the same guarantees to sharded clusters.
Today, MongoDB provides full multi-document ACID transactions even across sharded, distributed clusters. That reliability is why Wells Fargo runs its credit card payment platform on MongoDB, and why Citizens Bank built its real-time fraud detection system there.
Queryable Encryption: querying data that stays encrypted
MongoDB 8.0 expanded Queryable Encryption (QE) to support range queries. This means MongoDB can filter and compare against encrypted field values while the data remains encrypted at rest. In regulated industries like financial services and healthcare, QE delivers compliance and query performance at the same time.
5. Technical reason ④ Atlas Vector Search — the core weapon for the AI era
What vector search is
Traditional keyword search returns results only when words match exactly. Vector search finds results based on semantic similarity.
Searching "heart attack symptoms" with keyword search returns only documents containing that exact phrase. Vector search also surfaces "chest pain," "pressure in the chest," and "numbness in the left arm" — because they are semantically related.
This is the foundational infrastructure for RAG (Retrieval-Augmented Generation) AI applications. When an LLM needs to generate an accurate response, vector search retrieves the precise contextual data in real time, dramatically reducing hallucination.
What makes MongoDB Atlas Vector Search different
MongoDB did not simply bolt on a vector search feature. Vector data is stored in the same document as the operational data that produced it. This means no separate vector database is needed — the architecture is simpler and data synchronisation problems disappear.
Atlas Vector Search uses HNSW (Hierarchical Navigable Small World) for ANN (Approximate Nearest Neighbor) search and supports vectors up to 4,096 dimensions.
Hybrid Search: keywords and semantics, together
In production AI applications, combining keyword search and vector search in a single Hybrid Search pipeline typically delivers the best results. MongoDB Atlas runs both in one query pipeline.
Novo Nordisk's reduction of clinical report authoring from 12 weeks to 10 minutes, and Sentra's 180x query speed improvement, both relied on this integration of Atlas Search and Vector Search.
Voyage AI integration: domain-specific embedding accuracy
In February 2025, MongoDB acquired Voyage AI. Voyage AI's embedding models outperform general-purpose models in specialised domains like finance, law, and medicine. That accuracy advantage is a decisive factor in reducing hallucination for domain-specific AI applications.
6. Technical reason ⑤ MongoDB 8.x — the fastest release ever built
MongoDB 8.0: a step-change in performance
For MongoDB 8.0, the organisation assembled what it called a "Performance Army" — an explicit company-wide effort to reach record levels on all four enterprise dimensions simultaneously: security, durability, availability, and performance.
The numbers speak for themselves.
| Workload | Improvement vs MongoDB 7.0 |
|---|---|
| Read-heavy | +36% |
| Mixed read/write (95/5) | +32% |
| Bulk insert | +54% |
| Replication | +20% |
| Time-series aggregation | +60% |
| Sharding data distribution | Up to 50x faster |
MongoDB's own internal build system reported a ~75% reduction in query latency after upgrading to 8.0. Felix Horvat, CTO of the German climate-tech startup OCELL, noted that certain queries ran twice as fast after moving to 8.0.
MongoDB 8.1 and 8.2: continued refinement
MongoDB 8.1 added further improvements.
- Time-series bulk insert throughput: up to +195%
- Match-filter query throughput: up to +40%
- Array-containing document queries: up to +20%
- CPU utilisation: up to 5% reduction
MongoDB 8.2 is a subsequent minor release that includes faster initial sync and reduced query multi-planning overhead.
Performance figures are drawn from MongoDB's official release notes and benchmarks. Actual results vary by workload.
7. Technical reason ⑥ Security and compliance — why enterprises trust it
Financial services, healthcare, and public sector organisations evaluate security and compliance before performance when choosing a database. MongoDB has built a comprehensive stack to meet those requirements.
The security feature stack
Role-Based Access Control (RBAC) lets administrators define precise read, write, and admin permissions per user or role. Audit Logs record who accessed or modified which data and when.
Field-Level Encryption (FLE) encrypts individual sensitive fields at rest. A social security number or payment card number stored with FLE cannot be read in plaintext even by a database administrator.
Queryable Encryption goes further: it enables range queries and comparison operations against encrypted data while it remains encrypted. This is the combination of compliance and query performance that highly regulated workloads require.
Global compliance coverage
MongoDB integrates with AWS PrivateLink for fully private network connectivity, supporting GDPR, HIPAA, DSCSA, and financial industry regulations.
Deutsche Telekom configured Atlas to shard customer data exclusively within European regions to satisfy GDPR data residency requirements. This kind of granular data sovereignty control — per-region data pinning without platform replacement — is a key differentiator for global enterprises operating under multiple regulatory frameworks.
8. Technical reason ⑦ Developer experience (DX) — speed as competitive advantage
JSON-native: the application object and the database record are the same thing
Nearly all modern web and mobile applications exchange data in JSON. MongoDB's document model uses the same structure, so the objects an application works with can be stored and retrieved from the database directly — no ORM (Object-Relational Mapping) layer, no schema translation code.
MCP support: natural-language database interaction for AI developers
In 2025, MongoDB released an official MCP (Model Context Protocol) server. MCP is an open standard originally introduced by Anthropic to enable AI agents to communicate with data systems.
The practical implication is significant. Developers using AI coding tools like Cursor, GitHub Copilot, or Claude can ask questions about and manipulate a MongoDB database in plain language. Typing "show me the five best-selling products last week" causes the AI agent to generate and execute the appropriate query and return the result.
MongoDB reports that the MCP server launch has driven a sustained increase in new projects started on the platform each week, with large enterprise customers adopting MongoDB MCP as a core component of their agentic AI stack.
The figure "thousands of new projects per week" reflects early post-launch momentum as reported by MongoDB. External verification of the precise weekly count is not available.
Atlas operational automation: reducing DevOps overhead
MongoDB Atlas automates cluster management, backups, performance monitoring, automatic index suggestions, and anomaly detection. Enterprise teams have reported significant reductions in operational overhead, freeing engineers to focus on business logic rather than infrastructure management.
9. Side-by-side comparison: MongoDB vs relational databases
| Technical area | Relational DB (PostgreSQL, MySQL, etc.) | MongoDB |
|---|---|---|
| Data model | Table-based (fixed schema) | Document-based (flexible schema) |
| Scaling strategy | Vertical (Scale-Up) | Horizontal (Scale-Out, sharding) |
| ACID transactions | Full support (decades of history) | Full support (MongoDB 4.0+, including sharded clusters) |
| JOINs | Complex JOINs supported | Largely unnecessary via document embedding |
| Schema changes | ALTER TABLE (downtime risk) | New field added immediately |
| Vector search | Requires extension (pgvector, etc.) | Built into Atlas natively |
| AI integration | Complex multi-system pipeline | Operational data + vector embeddings on one platform |
| Multi-cloud | Separate configuration per cloud | AWS, Azure, and GCP unified under Atlas |
| Developer ergonomics | SQL-based, ORM required | JSON-native, intuitive API |
This comparison does not imply that relational databases are universally inferior. For highly normalised, complex relational data or for specific OLAP workloads that depend on decades of SQL query optimisation, relational databases retain clear strengths. MongoDB's advantage is most pronounced for modern application environments that require rapidly evolving data structures, large-scale horizontal expansion, and deep AI integration.
10. Part 3 wrap-up and what's next
The seven technical advantages covered in this post can be summarised as follows.
| Technology | Core value |
|---|---|
| Document model | Natural data representation without JOINs; 30–50% shorter development cycles |
| Horizontal scaling (sharding) | Handles any volume growth; MongoDB 8.0 distributes data up to 50x faster |
| ACID transactions | Enterprise trust in finance and healthcare; full support on sharded clusters |
| Atlas Vector Search | Operational data + vector embeddings on one platform; foundational RAG infrastructure |
| MongoDB 8.x | Reads +36%, mixed workloads +32%, time-series aggregation +60% |
| Security & compliance | FLE, Queryable Encryption, data sovereignty |
| Developer experience (DX) | JSON-native, MCP support, Atlas operational automation |
Part 4 covers putting all of this into practice. We will walk through what to prepare for a migration from a relational database to MongoDB, which pitfalls to avoid, and how data modelling needs to change — presented as a practical field guide.
If this post was useful, bookmark the full series. Part 4 will be published soon.
References
- MongoDB 8.0: Raising the Bar
- MongoDB 8.0: Improving Performance, Avoiding Regressions
- Release Notes for MongoDB 8.2
- MongoDB Atlas Vector Search
- Busting The Top Myths About MongoDB Vs Relational Databases
- Why Relational Databases Are So Expensive To Enterprises
- Converged Datastore For Agentic AI — MongoDB
- AI Fraud Detection With MongoDB Atlas and Temporal