- Home
- Skills
- Williamzujkowski
- Cognitive Toolworks
- Database Mongodb Architect
database-mongodb-architect_skill
- Python
5
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill williamzujkowski/cognitive-toolworks --skill database-mongodb-architect- SKILL.md26.2 KB
Overview
This skill designs and optimizes MongoDB database architectures focused on document modeling, indexing (ESR rule), sharding, aggregation pipelines, replica sets, and WiredTiger tuning. It delivers fast schema reviews, complete production designs, and enterprise migration guidance with concrete config snippets and measurable recommendations. Use it to get actionable indexing, sharding, replication, and performance tuning advice tailored to workload and deployment constraints.
How this skill works
I inspect workload type (OLTP, OLAP, time-series, content, analytics), data volume estimates, access patterns, and MongoDB version (default 8.0). The skill runs a quick schema review path for fast index and modeling suggestions or a full architecture path producing schema validation, ESR-based index definitions, shard-key choices, aggregation optimizations, replica set topology, and WiredTiger/connection-pool tuning. Outputs include prioritized quick wins, detailed configs, and migration/enterprise recommendations when requested.
When to use it
- Design a new MongoDB deployment for production or SaaS multi-tenant app
- Review or refactor an existing schema to reduce query latency
- Plan sharding strategy for growing datasets and avoid hotspots
- Optimize aggregation pipelines and reduce memory sort overhead
- Configure replica sets and read/write concerns to meet SLAs
- Tune WiredTiger cache and connection pools for working set fit
Best practices
- Apply ESR for compound indexes: Equality fields first, Sort fields next, Range fields last
- Embed for bounded 1-to-many, reference for high-cardinality or many-to-many
- Choose shard key to balance distribution and query targeting (hashed vs ranged vs compound)
- Match early and project late in aggregation pipelines; use indexes to avoid in-memory sorts
- Size WiredTiger cache to hold the working set (≈50–62.5% RAM) and monitor evictions
- Set writeConcern and readPreference explicitly to match durability and latency needs
Example use cases
- Quick schema review: return modeling decision, 3–5 ESR index recommendations, and top bottlenecks
- Full architecture for OLTP app: schema validation, compound indexes, hashed shard key, 3-node replica set config
- Time-series design: ranged sharding on timestamp, zone sharding for retention tiers, optimized aggregation
- Migration plan to MongoDB 8.0: replica set upgrades, queryable encryption for PII, and config tuning
- Multi-region deployment: tagged replica members, read preferences by region, and latency-first reads
FAQ
Provide workload type, read/write ratio, estimated document counts and sizes, growth rate, query patterns, and deployment context (cloud vs self-hosted). Without these, sizing is generic.
How does ESR improve query performance?
ESR orders compound index keys to maximize index usability: equality filters first enable index prefixing, sort keys next allow index-backed sorts, and range keys last reduce index selectivity issues.
When should I prefer hashed vs ranged shard keys?
Use hashed keys for even write distribution and to avoid hotspots; use ranged keys for efficient range queries (time-series) or when query targeting by range is required.