# Compass Anti-Patterns > Source-anchored research for Compass Anti-Patterns. Run status: COMPLETED. Parent: [MongoDB Compass](https://llms-explorer.com/tree/mongodb-compass/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/compass-anti-patterns/ ## How it works - When reviewing a collection in Compass, unnecessary indexes and bloated documents are legitimate investigation targets. MongoDB documents their disk-space, write-cost, and query-performance consequences; the presence of an index or a large document alone does not establish that it is unnecessary or bloated. (low confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns.md) ## Problems, failure modes and limitations - MongoDB's schema anti-pattern catalogue covers unbounded arrays, excessive collection counts, unnecessary indexes, bloated documents, and excessive $lookup operations. Independent research catalogues related MongoDB smells; its literature synthesis is corroborating context, not an independent measurement of Compass detection coverage. (high confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns.md) - Allowing an embedded array to grow without a bound can exhaust document-size limits and impose resource costs. MongoDB documents its 16 MB BSON limit; independent document-database research reports the same general growth hazard. (high confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns/unbounded-arrays.md) - An anti-pattern warning does not justify banning arrays. MongoDB recommends bounded subsets for some access patterns, while independent research treats a bounded order-line array as sensible and an entire customer order history as unsafe nesting. (high confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns/unbounded-arrays.md) - COMPASS-9163 reports that importing a numeric embedding array of 251 elements triggers a large-array warning. Its report distinguishes import warning logic from schema insight logic. This establishes a reported warning mismatch, not universal behavior across Compass releases. (low confidence) (verified as of 2026-06-19) — [source](https://jira.mongodb.org/browse/COMPASS-9163) - Treating a Compass schema sample as a complete data-quality audit is an anti-pattern. Sampling can omit rare fields or type variants; use targeted checks for exceptional records before concluding that they do not exist. (high confidence) — [source](https://www.mongodb.com/docs/compass/sampling.md) - An embedded history that grows without a bound is a design risk even when it initially looks convenient in Compass. Growing arrays can strain resources and eventually exceed document limits; bounded subsets or separately stored related records can address the growth. (high confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns/unbounded-arrays.md) ## Comparisons and alternatives - Fixing unbounded arrays involves trade-offs: a bounded subset duplicates data and makes updates more expensive, while external references can require additional queries and latency. Select the remedy for the workload rather than treating every join as a design error. (medium confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns/unbounded-arrays.md) - Increasing schema-analysis coverage has a cost: larger samples or whole-collection inspection require more time and processing. Use query filters to investigate relevant document segments rather than assuming one broad sample answers every question. (high confidence) — [source](https://www.mongodb.com/docs/compass/sampling.md) ## Facts and statements - Replacing embedded objects with an ever-growing array of their IDs does not necessarily remove unbounded growth. The document-database design paper explicitly warns about customer documents that retain every order reference; assess the cardinality and growth of references as well as embedded objects. (medium confidence) — [source](https://www.vldb.org/pvldb/vol18/p4804-carey.pdf) - Unnecessary indexes and bloated documents deserve explicit review: the vendor describes storage and write costs from excess indexes and common-query costs from large documents; the research mapping reports the same categories and working-set pressure. (high confidence) — [source](https://www.mongodb.com/docs/manual/data-modeling/design-antipatterns.md) - Compass sampling documentation describes a 1,000-document $sample aggregation over a collection or query-selected subset. Treating such a sample as proof that no rare schema defect exists is an inference the evidence does not support. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/compass/sampling.md) - A schema-flexible database does not make inconsistent representations free. OneUptime recommends inspecting mixed field types, and independent document-database research explains that switching a logical value between scalar and array forms or mixing numeric and string representations complicates queries. This is design guidance, not evidence that Compass automatically flags every instance. (medium confidence) — [source](https://oneuptime.com/blog/post/2026-03-31-mongodb-compass-schema-analysis/view) - Using data values such as dates as field names can make range queries awkward and prevent straightforward secondary indexing. The document-database design paper recommends explicit fields for those values; this is an additional manual review check, not a documented Compass detector. (low confidence) — [source](https://www.vldb.org/pvldb/vol18/p4804-carey.pdf)