Skip to content

Data Modeling

Unbounded Arrays

Why an array that grows forever will eventually make the document unusable.

IntermediateAbout 5 minutes

A document cannot exceed 16MB. Long before that, a huge array hurts: every read pulls the whole thing, every $push rewrites the document, a multikey index gets one key per element. If you cannot name a cap ('this checkout', 'max 50 tags'), it does not belong in the parent.

// Events, messages, notifications, order history — not an array on the user
{ name: "Rahul", events: [ /* $push every click, forever */ ] }
The shape that fails in production
  • Outbound collection. events documents with userId + createdAt. Index that pair. The user document stays a profile.
  • Subset. Store recentComments (last 20) on the post for the render path; the rest live in comments. Accept that the subset is a cache.
  • Buckets. Fixed-size chunks (100 readings per document) for time series / chat. New document when the bucket is full. The interview answer for 'sensor data'.

skills of length 2 is not unbounded. items of length 3 is not. orderIds that $push on every purchase is. The test: will this still be a comfortable findOne in two years?

Interview question

Why is an unbounded array inside a document a problem?

Think about it first.