MongoDB
7.xSummary
Document-oriented database storing JSON-like BSON documents, with flexible schemas, multi-document ACID transactions, horizontal sharding, and a rich aggregation pipeline.
Primary Use Case
Applications with evolving schemas, hierarchical document data, or workloads where the flexibility of schemaless storage reduces application complexity compared to relational normalization.
Workload Fit
Strengths
Best for
- ·Applications with frequently changing schemas that make relational migrations expensive
- ·Hierarchical or nested document data that maps awkwardly to relational tables
- ·Product catalogs, content management, and user profiles with variable attributes
- ·Rapid prototyping where schema flexibility accelerates early development
Excels when
- ·Document structure varies significantly across records (polymorphic schemas)
- ·Read access patterns access entire documents rather than specific columns
- ·Query patterns align with document structure rather than relational joins
Architectural advantages
- ·Flexible BSON schema eliminates costly relational migrations for evolving data models
- ·Rich aggregation pipeline replaces many analytical JOIN queries without a separate analytics layer
- ·Multi-document ACID transactions (v4.0+) enable transactional semantics on document operations
- ·Native horizontal sharding enables write scaling without application-layer routing
When to Avoid
Avoid when
- ·Workload is highly relational with many cross-document joins: PostgreSQL handles this better
- ·Schema flexibility is not needed: fixed schemas in PostgreSQL have better tooling and performance
- ·Cost is a primary concern: MongoDB Atlas is significantly more expensive than PostgreSQL equivalents
Common misuses
- ·Using MongoDB for relational data to avoid schema design: results in $lookup-heavy queries that outperform PostgreSQL joins poorly
- ·Not defining indexes: MongoDB collection scans are as slow as PostgreSQL sequential scans
- ·Using multi-document transactions pervasively: ACID transactions have significant performance overhead
Consistency & Transactions
Scaling
Read scalability
Secondary replica set members serve read operations with configurable read preference. Sharding distributes collections across shard servers, enabling horizontal read and write scaling.
Write scalability
Sharded clusters distribute writes by shard key. Choosing a poor shard key creates write hot spots. Choosing a good shard key enables near-linear write scaling across shards.
Failure Behavior
Known failure modes
- ·Hot shard key: writes concentrate on a single shard, defeating horizontal scaling
- ·Working set exceeds RAM: index and data eviction causes disk I/O latency spikes
- ·Replica set election during primary failure: 10-30 second write unavailability window
- ·Orphaned documents after failed chunk migrations in sharded clusters
Bottlenecks
- ·Working set exceeding RAM causes index and data page eviction and disk read latency
- ·Hot shard key concentrating writes on a single shard nullifies horizontal scaling
- ·Large documents (>16MB limit) or unbounded embedded arrays slow document reads
Degradation patterns
- ·Index bloat from high write rates increases memory pressure over time
- ·Shard imbalance from poor shard key choice accumulates without automatic rebalancing
- ·Replica set election window causes 10-30s write unavailability under primary failure
Recovery considerations
- ·Replica set elections are automatic but incur 10-30 second write unavailability
- ·Atlas continuous backup enables point-in-time recovery; self-hosted requires custom backup pipeline
- ·Chunk migration failures in sharded clusters can leave orphaned documents requiring cleanup
Operational Pitfalls
- ·Using ObjectId as shard key: monotonically increasing keys create write hot spots on the last shard
- ·Not indexing query fields: collection scans on large collections cause latency spikes
- ·Embedding unbounded arrays in documents: array size growth degrades read performance
- ·Using multi-document transactions for simple operations: ACID transactions add significant overhead
Architecture Guidance
Common topology roles
Migration notes
- ·From PostgreSQL: JSON columns in PostgreSQL can replace many MongoDB use cases without migration cost
- ·From MongoDB to PostgreSQL: flatten document hierarchies into relational tables; add indexes on queried fields
- ·To Atlas: wire-compatible with self-hosted; Atlas auto-sharding simplifies horizontal scaling management
Advisor Guidance
When: scenario has highly_relational data with frequent cross-document joins
Consider PostgreSQL for relational data: $lookup joins in MongoDB have higher overhead than SQL joins
When: scenario uses MongoDB sharding
Shard key selection is irreversible after data migration: validate write distribution before sharding
When: scenario has flexible_schema or evolving data model
Define index patterns early: schemaless storage does not eliminate the need for query-driven index design
Comparison Factors
schema flexibility
High: BSON document model adapts to evolving data requirements without migrations
relational query capability
Low: $lookup aggregations are inefficient for normalized relational data
operational complexity
Medium: replica sets are straightforward; sharding adds significant operational complexity
cost
Medium to high: Atlas pricing is premium; self-hosted costs are comparable to PostgreSQL
Managed Cloud Options
Enables Patterns
Basis
Widely deployed; operational characteristics well-documented in production engineering posts
Learning Modules
Consistency Models in Distributed Systems
The consistency spectrum from linearizability to eventual consistencywhat each model guarantees, which real systems implement each model, and how to design application code for the consistency level your infrastructure provides.
Event Sourcing
Store a sequence of immutable domain events as the source of truth; derive current state by replaying the event log. Understand projections, snapshots, event versioning, and the operational tradeoffs that make event sourcing correct in some systems and wrong in others.