MongoDB Design and Usage Assistant

Design Problems It Addresses

MongoDB is not just a relational table copied into document storage. Real projects usually get stuck on specific trade-offs: should order, user, and address be embedded or referenced? Why does composite index field order matter? How do $match, $unwind, and $lookup affect index usage in aggregation pipelines? Why is a poorly chosen sharding key hard to fix later? If these decisions rely only on habit, common production consequences include slow queries, documents near the 16MB limit, unbounded arrays, excessive nesting, or a shard key becoming a write hotspot.

How the Skill Works

The skill follows a MongoDB design workflow rather than generating generic queries. It detects intent around document modeling, embed vs reference decisions, index design, aggregation planning, or sharding. Core capabilities include:

• Embed/reference guidance: reasons to embed or reference based on access patterns, growth, relationship type, and single-document atomic updates.
• Index rules: composite ordering as Equality → Sort → Range, plus cautions about $match before $unwind and covered queries projecting only indexed fields.
• Schema patterns: Attribute, Bucket, Document Versioning, Extended Reference, Polymorphic, Subset, Tree, and other common patterns for mapping business structures to documents.
• Version checks: loads MongoDB version features up to the target version and flags deprecations, major changes, and new modules to avoid incompatible design assumptions.

Boundaries and Caveats

It is useful for design reviews, pre-implementation modeling, and migration references from relational databases to MongoDB. It does not replace load testing or real index validation; production decisions should still use explain, data distribution, write patterns, TTL, text indexes, and operations constraints. Hard limits are explicit: keep documents under 16MB, keep arrays under about 1000 elements, prefer embedding over $lookup when possible, choose shard keys carefully, and avoid monotonically increasing shard keys that can create hotspots.