Thursday, May 7, 2026
All posts
Lv.2 BeginnerMongoDB
25 min readLv.2 Beginner
SeriesWhy Enterprises Choose MongoDB · Part 3/4View series hub

Why Enterprises Choose MongoDB Part 3 — Technical Reasons In Depth

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

  1. Introduction — "It's good" — but why, exactly?
  2. Technical reason ① The document model — tearing down the relational wall
  3. Technical reason ② Horizontal scaling (sharding) — handling unpredictable growth
  4. Technical reason ③ ACID transactions — ending the "NoSQL can't do finance" myth
  5. Technical reason ④ Atlas Vector Search — the core weapon for the AI era
  6. Technical reason ⑤ MongoDB 8.x — the fastest release ever built
  7. Technical reason ⑥ Security and compliance — why enterprises trust it
  8. Technical reason ⑦ Developer experience (DX) — speed as competitive advantage
  9. Side-by-side comparison: MongoDB vs relational databases
  10. 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.

PropertyMeaning
AtomicityAll operations in a transaction succeed together or all fail together
ConsistencyData always remains in a valid state before and after a transaction
IsolationConcurrent transactions do not interfere with each other
DurabilityCommitted 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.

WorkloadImprovement vs MongoDB 7.0
Read-heavy+36%
Mixed read/write (95/5)+32%
Bulk insert+54%
Replication+20%
Time-series aggregation+60%
Sharding data distributionUp 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 areaRelational DB (PostgreSQL, MySQL, etc.)MongoDB
Data modelTable-based (fixed schema)Document-based (flexible schema)
Scaling strategyVertical (Scale-Up)Horizontal (Scale-Out, sharding)
ACID transactionsFull support (decades of history)Full support (MongoDB 4.0+, including sharded clusters)
JOINsComplex JOINs supportedLargely unnecessary via document embedding
Schema changesALTER TABLE (downtime risk)New field added immediately
Vector searchRequires extension (pgvector, etc.)Built into Atlas natively
AI integrationComplex multi-system pipelineOperational data + vector embeddings on one platform
Multi-cloudSeparate configuration per cloudAWS, Azure, and GCP unified under Atlas
Developer ergonomicsSQL-based, ORM requiredJSON-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.

TechnologyCore value
Document modelNatural 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 transactionsEnterprise trust in finance and healthcare; full support on sharded clusters
Atlas Vector SearchOperational data + vector embeddings on one platform; foundational RAG infrastructure
MongoDB 8.xReads +36%, mixed workloads +32%, time-series aggregation +60%
Security & complianceFLE, 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

Share This Article

Series Navigation

Why Enterprises Choose MongoDB

3 / 4 · 3

Explore this topic·Start with featured series

한국어

Follow new posts via RSS

Until the newsletter opens, RSS is the fastest way to get updates.

Open RSS Guide