MongoDB Data Modeling

Problem

MongoDB schemas often fail when they normalize too early or embed too aggressively. Lists may run repeated $lookup, detail pages may unwind large arrays, and oversized documents degrade writes. This skill helps developers choose a schema from query paths, write frequency, and document size before production pressure forces a rewrite.

Core workflow

The skill first checks whether MongoDB is the right tool: flexible documents, read-heavy workloads, JSON-shaped data, and horizontal scaling are good fits. Strict cross-document transactions, complex many-table joins, and fixed-schema reporting should usually favor PostgreSQL. It then applies the “read and write together” rule: one-to-one relations are often embedded; one-to-many relations are usually separate collections with references; low-cardinality references may use Extended Reference, such as caching author_name, while metrics like comment_count may use a Computed Pattern. Finally, it proposes indexes and pipelines aligned to the access path, for example articles: { created_at: -1, status: 1 } and comments: { article_id: 1, created_at: -1 }, and prefers $lookup plus $project or two targeted queries over $lookup + $unwind when that is cheaper.

Boundaries

Use it for schema selection, slow collection diagnosis, sharding strategy, and aggregation pipeline review. Avoid relying on it for strict ACID financial flows, complex OLAP, or multi-table reporting. It reads like an architecture checklist, not a substitute for workload profiling and capacity testing.