MongoDB
A document model that lets data structure follow access patterns, not schema migrations.
MongoDB's document model fits data that is read and written as a unit: hierarchical structures, variable-shape records, and workloads where co-locating related data in a single document reduces query complexity. It's the right fit when the access patterns are well-understood and the data has natural document boundaries — and the wrong fit when the application is fundamentally relational and reaches for $lookup everywhere.
My approach to MongoDB starts with access patterns, not an entity diagram. Before touching a schema I map out which queries run on the hot path, what they read, and how often they write — because document shape in MongoDB is a direct function of read/write ratio and query atomicity, not normalization theory. Embedding means a single-document read with no joins; referencing means flexibility at the cost of extra round-trips. The decision tree I use: embed when the data is always read together, has bounded growth, and doesn't need to be queried independently. Reference when the sub-document is queried on its own, grows unboundedly, or is shared across multiple parent documents. Transactions in MongoDB are a signal the data model is wrong — if I find myself reaching for a multi-document transaction to maintain consistency, I treat it as a prompt to revisit the document boundaries. On indexing, I start with explain() in executionStats mode, not guesswork. Compound index field order follows equality fields first, then range predicates, then sort fields — putting a range field before the sort field wastes the index's sort order. I use partial indexes for sparse queries to avoid indexing documents that will never match. Atlas Performance Advisor surfaces slow queries I haven't manually caught, but I treat it as a second pass, not a substitute for planning indexes against known query patterns upfront.
Data Model Design
I start by listing the read and write operations the application performs, ordered by frequency and latency sensitivity. Document shape follows from that list — embedding decisions are made against actual query patterns, not an abstract schema, and collection boundaries are drawn where the data is independently queryable.
Index Optimization
I run explain() in executionStats mode against the slow query log to identify collection scans and suboptimal index usage. Compound indexes are ordered by equality predicates first, range predicates second, sort fields last. Partial indexes go on fields that only appear in a subset of documents to avoid bloating the index with documents that will never match the query filter.
Atlas Setup & Operations
Atlas configuration starts with tier sizing based on working set size — the data and indexes that fit in RAM determine the cluster tier. I set the oplog window long enough to survive a maintenance window without hitting a stale oplog on a replica. Connection pool size is set per application instance with a ceiling that won't saturate the cluster's max connections under horizontal scaling.
Content & Catalog Systems
Product catalogs and content repositories with variable per-item attributes map well to the document model: each document carries exactly the fields relevant to that item type, and schema changes don't require altering a table or backfilling columns across millions of rows.
User Profile & Session Data
Hierarchical user documents — preferences, embedded activity records, nested configuration objects — are read and written atomically in a single document fetch. Embedding avoids the join overhead that comes with normalizing this structure across multiple tables.
Event Log & Time Series
Append-heavy workloads benefit from MongoDB's write scalability and, for fixed-interval data, the Time Series collection type which compresses measurements on disk and exposes a bucketing-aware query path that reduces scan cost significantly.
Let's talk MongoDB.
No pitch. Just a technical conversation about the problem you're working on.