MongoDB

MongoDB's document model suits data that does not map cleanly to rows — flexible, nested, evolving shapes. I use it where that flexibility is a real advantage, and I design the document boundaries as deliberately as I would a relational schema.

I am disciplined about the notorious traps: proper indexing for the query patterns, avoiding unbounded array growth, and using aggregation pipelines carefully. The trade-offs of denormalised design are evaluated against the read/write ratio it serves.

MongoDB pairs particularly well with event-sourced and content-heavy systems, where append-friendly documents and high write throughput fit the domain better than a fixed relational join table.

The document model is chosen deliberately, never by default. Where a shape is nested, varied, or evolving — content, logs, profiles — a document fits naturally; where rigid joins and invariants dominate, I reach for a relational engine instead.

Documents are designed like a schema, even though they are flexible. I define the shape, pick the keys, and decide what is embedded versus referenced based on the read/write ratio the data actually sees, not on what is easiest to type.

Indexing is what prevents the flexibility from becoming a slog. I write indexes and compound indexes matched to the real query patterns, and validate them against the workload before trusting them in production.

Aggregation pipelines handle analytics-shaped reads. When a query needs grouping, unwinding, or reshaping, the framework in the database does it in a controlled way rather than dragging documents into the application layer.

Scaling follows the deployment model. Replica sets protect availability and reads; sharding distributes writes and data across scale — and I introduce each only when the workload genuinely demands it.

The relational-versus-document decision is made per use case. I am as likely to use Postgres for one part of a system and MongoDB for another, choosing each engine because it fits that slice — not because the team is married to a single tool.

I choose the document model deliberately, never by default. Flexible, nested, evolving shapes fit MongoDB; rigid joins and invariants fit a relational engine, and I decide per use case.

Documents are designed like a schema even though they are flexible. I define the shape, pick the keys, and decide embed-vs-reference from the read/write ratio the data actually sees.

Indexes match the real query patterns. I write single-field and compound indexes for the actual access paths and validate them against the workload.

Unbounded array growth is a known trap, so I avoid it. Any inner array is evaluated for how large it can realistically become before it becomes a design decision.

Aggregation pipelines do analytics-shaped reads in the database, so I avoid dragging documents into the application layer for grouping and reshaping.

Replica sets protect availability and reads; sharding distributes writes and data across scale. I introduce each only when the workload genuinely demands it.

Atomicity bounds are respected. A document update is atomic, so I model operations that must be atomic within a single document boundary.

MongoDB composes with event-sourced and content-heavy systems where append-friendly documents and high write throughput fit the domain.

The honest trade-off is stated plainly. Where a relational engine serves a slice better, I use Postgres for that slice and MongoDB where documents genuinely win.