When to Use MongoDB
Choosing the right database is one of the most consequential architectural decisions you will make. Get it right and your data layer disappears into the background — fast, scalable, and easy to work with. Get it wrong and every feature becomes a fight against the schema, migration scripts pile up, and query performance degrades as the dataset grows.
MongoDB excels in specific scenarios. This page walks through those scenarios in detail — with real document shapes — and is equally honest about situations where a relational database is the better choice.
Content Management Systems
Content management is one of MongoDB's strongest use cases. A CMS stores many types of content — articles, landing pages, product descriptions, author profiles, media assets, FAQs — and each content type has a different set of metadata fields. In a relational database, you either create a table per content type (proliferating tables) or use an Entity-Attribute-Value pattern (notorious for poor query performance and schema chaos).
With MongoDB, each piece of content is a document. Different content types simply have different fields. Adding a new content type requires no schema migration — you start inserting documents with the new shape immediately. Editors can add custom metadata fields without a database administrator involved.
CMS: different content types in one collection
// A blog article
{
"_id": ObjectId("64b1..."),
"type": "article",
"slug": "getting-started-with-mongodb",
"title": "Getting Started with MongoDB",
"body": "MongoDB is a document database...",
"author": { "name": "Alice Johnson", "bio": "Senior Engineer at Acme" },
"tags": ["mongodb", "database", "nosql"],
"publishedAt": ISODate("2024-03-01T00:00:00Z"),
"readingTimeMinutes": 8,
"seo": { "metaTitle": "MongoDB Guide", "metaDescription": "..." }
}
// A product landing page (completely different fields)
{
"_id": ObjectId("64b2..."),
"type": "landing-page",
"slug": "enterprise-plan",
"headline": "Scale Without Limits",
"heroImage": "/images/enterprise-hero.jpg",
"features": [
{ "icon": "shield", "title": "Enterprise Security", "body": "SOC 2 Type II certified" },
{ "icon": "zap", "title": "99.99% Uptime SLA", "body": "Guaranteed availability" }
],
"ctaButton": { "label": "Start Free Trial", "href": "/signup" },
"updatedAt": ISODate("2024-05-10T14:00:00Z")
}E-Commerce Product Catalogs
Product catalogs are a textbook MongoDB use case because products have wildly different attributes depending on their category. A smartphone has a processor, RAM, camera megapixels, and battery capacity. A pair of shoes has size, material, and colour options. A book has an ISBN, author, and page count. In SQL you end up with dozens of nullable columns or a complex EAV schema. In MongoDB each product is a document with exactly the fields it needs.
Product catalog: category-specific attributes per document
// A smartphone
{
"_id": ObjectId("64c1..."),
"category": "electronics",
"subcategory": "smartphones",
"brand": "Acme",
"model": "ProMax 15",
"price": 999.99,
"stock": 142,
"specs": {
"processor": "A17 Bionic",
"ram": "8GB",
"storage": ["128GB", "256GB", "512GB"],
"camera": { "main": "48MP", "ultrawide": "12MP", "selfie": "12MP" },
"battery": "4422mAh",
"os": "iOS 17"
},
"images": ["/imgs/acme-promax-front.jpg", "/imgs/acme-promax-back.jpg"]
}
// A running shoe (entirely different attributes)
{
"_id": ObjectId("64c2..."),
"category": "footwear",
"subcategory": "running",
"brand": "Stride",
"model": "UltraRun 3",
"price": 129.99,
"stock": 88,
"specs": {
"material": "mesh upper, rubber outsole",
"dropMm": 8,
"weight": "280g",
"terrain": ["road", "track"]
},
"variants": [
{ "size": 9, "color": "Black/White", "sku": "SR3-9-BW", "stock": 12 },
{ "size": 10, "color": "Black/White", "sku": "SR3-10-BW", "stock": 7 },
{ "size": 10, "color": "Blue/Silver", "sku": "SR3-10-BS", "stock": 15 }
]
}Real-Time Analytics and IoT
IoT and real-time analytics workloads are defined by high-volume, continuous writes from many sources — temperature sensors, GPS trackers, application event streams, server metrics. The access pattern is almost always write-heavy with range queries over time windows.
MongoDB's native time-series collections (introduced in version 5.0) are specifically optimised for this pattern. They automatically compress time-ordered data, cluster documents by source and time window on disk, and provide a $setWindowFields aggregation stage for moving averages, cumulative sums, and other windowed computations.
IoT: time-series collection for sensor readings
// Create a time-series collection
db.createCollection("sensorReadings", {
timeseries: {
timeField: "timestamp", // required: the field holding the date
metaField: "sensorId", // groups data by sensor for compression
granularity: "seconds" // hint for storage optimisation
},
expireAfterSeconds: 2592000 // auto-delete after 30 days
})
// Insert a batch of sensor readings
db.sensorReadings.insertMany([
{ sensorId: "boiler-01", timestamp: new Date(), temperature: 87.3, pressure: 1.02 },
{ sensorId: "boiler-01", timestamp: new Date(), temperature: 87.6, pressure: 1.03 },
{ sensorId: "pump-07", timestamp: new Date(), flowRate: 14.2, vibration: 0.04 },
])
// Query: average temperature per sensor over the last hour
db.sensorReadings.aggregate([
{
$match: {
timestamp: { $gte: new Date(Date.now() - 3600 * 1000) }
}
},
{
$group: {
_id: "$sensorId",
avgTemp: { $avg: "$temperature" },
maxPressure: { $max: "$pressure" }
}
}
])User Profiles and Personalisation
User profiles accumulate data over time — preferences, notification settings, browsing history, saved items, loyalty points, connected social accounts. This data is deeply nested and varies per user. Reading a user profile is almost always a single-document lookup by _id or email, making embedding the natural choice.
User profile: nested preferences and activity
{
"_id": ObjectId("64d1..."),
"email": "alice@example.com",
"displayName": "Alice Johnson",
"avatarUrl": "https://cdn.example.com/avatars/alice.jpg",
"preferences": {
"theme": "dark",
"language": "en-US",
"notifications": {
"email": { "marketing": false, "transactional": true },
"push": { "newMessage": true, "weeklyDigest": false }
},
"privacyLevel": "friends"
},
"loyaltyPoints": 1240,
"savedItems": [
ObjectId("64c1..."),
ObjectId("64c2...")
],
"recentSearches": ["mongodb tutorial", "node.js performance"],
"connectedAccounts": [
{ "provider": "google", "providerId": "109876543210", "linkedAt": ISODate("2023-01-10T00:00:00Z") },
{ "provider": "github", "providerId": "ghuser12345", "linkedAt": ISODate("2023-03-22T00:00:00Z") }
],
"createdAt": ISODate("2023-01-10T00:00:00Z"),
"lastLoginAt": ISODate("2024-06-15T09:41:00Z")
}Mobile and Gaming Applications
Mobile apps and games share a requirement: fast reads from a JSON-native API with minimal server-side transformation. A REST or GraphQL API serving a mobile client typically serialises data to JSON anyway — with MongoDB the data is already JSON-shaped in the database, so there is no object-relational mapping layer to maintain.
Gaming leaderboards, player inventories, and match histories are also excellent fits. Player data can be embedded per-user, ranked queries use indexed fields for O(log n) lookups, and the write throughput of multiplayer games maps well to MongoDB's horizontal write scaling.
Gaming: leaderboard query and player inventory
// Top 10 players by score in a given game mode
db.players.find(
{ "stats.gameMode": "ranked" },
{ displayName: 1, "stats.rating": 1, "stats.wins": 1 }
).sort({ "stats.rating": -1 }).limit(10)
// Add an item to a player's inventory atomically
db.players.updateOne(
{ _id: playerId },
{
$push: {
inventory: {
itemId: "legendary-sword-01",
name: "Voidbreaker",
rarity: "legendary",
acquiredAt: new Date()
}
},
$inc: { "stats.itemsCollected": 1 }
}
)When NOT to Use MongoDB
Highly relational data with frequent ad-hoc JOINs — if your application constantly queries across 10+ tables with complex join conditions, a relational database's query planner will outperform MongoDB's $lookup pipeline.
Complex multi-entity transactions across dozens of tables — while MongoDB supports multi-document transactions, workloads where every operation touches many collections with complex rollback logic are more natural in SQL.
Team expertise is entirely SQL and time-to-market is tight — switching paradigms has a real learning cost. If the whole team knows PostgreSQL and the deadline is imminent, lean on what you know.
Core business is SQL-native BI and reporting — tools like Crystal Reports, SSRS, and some BI platforms assume a SQL interface. Using the MongoDB BI Connector adds a translation layer that can complicate support.
Regulatory or compliance requirements mandate a specific RDBMS — some enterprise compliance frameworks specify approved database platforms. Check before you build.
The Data Structure Test
When evaluating whether MongoDB is the right fit, ask these questions about your data:
If your data looks like... | Consider... |
A flat table where every record has the same fields | SQL — the relational model fits naturally |
Nested objects or arrays within a record | MongoDB — embedding eliminates JOINs |
Different records with different fields | MongoDB — flexible schema avoids nullable columns |
High-volume time-stamped events from many sources | MongoDB time-series collections or a dedicated time-series DB |
Complex aggregations across many independent entities | SQL or a dedicated data warehouse (BigQuery, Redshift) |
Graph relationships (many-to-many traversals) | A graph database (Neo4j, Amazon Neptune) |
Real-World Companies Using MongoDB
MongoDB is battle-tested at scale across many industries. Some notable production deployments include:
Forbes — Content management system powering forbes.com. Variable article metadata and rich media objects mapped naturally to MongoDB documents.
eBay — Metadata storage for product listings. Millions of new listings per day with product attributes that vary widely by category.
Uber — Geospatial data for driver location tracking and trip history. MongoDB's geospatial indexing supports radius-based driver-matching queries.
Bosch — Industrial IoT platform ingesting sensor data from manufacturing equipment across global facilities.
The Weather Channel — Time-series weather data storage and real-time aggregation for weather.com.
Barclays — Financial services using MongoDB for trading data and reporting dashboards with flexible document schemas.
Electronic Arts — Player profile and game state storage for titles like FIFA, Apex Legends, and Battlefield.