What are the implications of the 16MB document limit on your modelling choices?
The 16MB BSON document limit fundamentally shapes MongoDB data modeling by forcing designers to consider document growth patterns, array sizes, and the choice between embedding and referencing to ensure documents stay within size constraints.
The 16MB BSON document limit is a hard constraint in MongoDB that significantly influences schema design decisions. Unlike traditional databases where row sizes are typically small, MongoDB's document model encourages embedding related data, but the 16MB limit creates a practical ceiling on how much you can embed. This affects everything from how you model relationships to how you handle arrays, log data, and time-series information. Understanding this limit is crucial because exceeding it causes write operations to fail, and even approaching it can degrade performance due to increased memory pressure and network transfer times.
- 1
Array size constraints: Arrays must be sized to prevent unbounded growth. The "Unbounded Array" anti-pattern occurs when arrays can grow indefinitely, eventually hitting the 16MB limit. Solutions include referencing or the bucket pattern.
- 2
Embedding vs. referencing trade-offs: The 16MB limit often forces the decision to reference rather than embed. If a user can have thousands of orders, embedding them all would exceed the limit, making referencing the only viable choice.
- 3
Document growth patterns: Documents that receive frequent updates with new fields or array elements must be modeled with growth in mind. Fields like
lastSeentimestamps don't cause growth, but accumulating historical data does. - 4
GridFS for large files: When you need to store files larger than 16MB, MongoDB provides GridFS, which splits files into chunks and stores them in two collections, but this is specialized for file storage, not general data modeling.
- 5
Performance considerations: Large documents (over a few MB) consume more memory and bandwidth. Even before hitting the limit, documents over 1-2 MB can degrade query performance because MongoDB must load them entirely into RAM.
To work within the 16MB limit, several patterns have emerged. The Subset Pattern embeds only the most recent or frequently accessed data (e.g., 10 most recent comments) while storing the full history in another collection. The Bucket Pattern groups time-series data into fixed-size windows (hourly buckets with 60 readings). The Extended Reference pattern stores a limited subset of frequently accessed fields from related documents. These patterns balance the benefits of embedding against the 16MB constraint.
To understand the practical impact, consider a blog post document. If each comment averages 500 bytes, you could store approximately 33,000 comments before hitting 16MB. For a product catalog, if each product variant is 200 bytes, 80,000 variants could fit. These limits might seem generous, but when documents contain multiple arrays or large embedded objects, the limit becomes a real constraint. A user document with 10 years of order history, each order averaging 2KB, could hold only 8,000 orders—insufficient for many e-commerce applications.
Scenario Questions
0-2 years experience
- 1Suppose you need to store a user's activity log that can grow over time. How would you model it in MongoDB given the 16 MB document limit?
- 2If you try to insert a document that exceeds 16 MB, what error do you see and how would you handle it in your application code?
2-5 years experience
- 1We have a product catalog where each product can have hundreds of reviews. Your team tried embedding all reviews in the product document and started hitting the 16 MB limit. Walk me through how you would refactor the schema and what trade‑offs you consider.
- 2During a recent deployment, a batch job failed because some order documents grew beyond 16 MB after adding a new field. How would you diagnose the issue and decide whether to split the document or change the data model?
5-8 years experience
- 1Design a high‑throughput analytics pipeline that writes user events to MongoDB. How does the 16 MB limit influence your choice between a single collection with large documents versus a sharded design with smaller documents?
- 2Our service stores aggregated metrics in a single document per day, and we’re approaching the size limit. What strategies would you employ to keep the system performant and avoid hitting the limit at scale?
8+ years experience
- 1Across multiple microservices we have overlapping data models that each embed large sub‑documents. How would you approach a company‑wide migration to respect the 16 MB limit while minimizing coupling and downtime?
- 2If a legacy system relies on very wide documents for audit trails, what long‑term architectural changes would you propose to handle the size constraint and support future feature growth?
Follow-up Questions
- Can you walk me through a concrete example where you had to split a large document?
- What monitoring or alerts would you set up to catch documents approaching the size limit?
- How would you test that the new schema still meets latency and throughput requirements?