What is the 'Unbound Array' problem and how do you solve it?

The most straightforward solution is to move the array to a separate collection and use references. This completely eliminates the unbounded growth because each related item becomes its own document [citation:1][citation:2]. Each document stays small, and you can query the related collection efficiently. The trade-off is that you may need $lookup aggregations to reunite the data, which adds query latency [citation:1][citation:4]. This is the right choice when the relationship is truly one-to-many and the 'many' side can grow arbitrarily large [citation:5][citation:7][citation:10].

For use cases where you only need a limited number of recent items (like displaying the 3 most recent reviews), the Subset Pattern is ideal [citation:2]. You embed a fixed-size subset of the most relevant data in the parent document, while storing the full history in a separate collection. This gives you fast access to the data you actually need while avoiding unbounded growth. This pattern works well when you have a natural recency requirement and updates to the subset are infrequent [citation:2][citation:9].

The Bucket Pattern is a hybrid approach where you group related items into fixed-size "buckets" [citation:7]. For example, instead of storing each user activity event as a separate document or as an infinite array, you create documents that contain, say, 100 events each. This gives you the best of both worlds: document size stays bounded, but you still get efficient access to groups of related data. This pattern is particularly effective for time-series data [citation:5][citation:7].

The right solution depends on your access patterns and constraints [citation:7][citation:10]. Choose referencing when you truly need to access all related items individually and the relationship can grow arbitrarily large [citation:1][citation:5][citation:10]. Choose the subset pattern when you only need a limited, recent slice of the data for display [citation:2]. Choose the bucket pattern for high-volume sequential data like logs, events, or time-series where you can group items naturally [citation:5][citation:7]. The MongoDB Schema Advisor now includes automated detection of unbounded arrays, highlighting collections where arrays exceed recommended sizes [citation:3][citation:6].

A classic unbounded array case is social media followers. Storing followers in an array within the user document is a disaster waiting to happen [citation:10]. With millions of users, a celebrity's document would quickly exceed 16MB. The solution is to create a separate follows collection with two fields: follower_id and following_id. This supports millions of followers without any document size risk, and indexes on both fields make queries efficient [citation:10]. This referencing approach scales linearly with data volume rather than exponentially.