Model from access patterns

In a relational database you model the data, then write whatever queries you need. MongoDB works better the other way around: model from access patterns. List the questions the application asks, the fields it changes together, and how each collection grows. The schema falls out of that list.

Take a small publishing app. Before designing anything, write the workload down:

Reads (most frequent first)
  R1: article page — article + author name + comments     every page view
  R2: homepage — latest 20 article summaries              every visit
  R3: author profile — author + their article titles      occasional

Writes
  W1: add a comment to an article                         frequent
  W2: publish an article                                  a few per day
  W3: update an author bio                                rare

Now design documents that serve R1 and R2 in one read each. An articles document can carry its title, body, a copy of the author’s display name, and recent comments. The homepage query then needs a projection of the same collection, nothing else.

{
  _id: ObjectId('...'),
  title: 'Modeling in MongoDB',
  authorId: ObjectId('...'),
  authorName: 'Flavio',
  comments: [ { user: 'anna', text: 'Great post' } ],
  publishedAt: ISODate('2026-08-03T09:00:00Z')
}

What a flexible schema will not rescue

Three shapes become expensive later no matter how flexible the schema is.

Unbounded arrays. Comments on a popular article grow forever. A document has a 16 MB hard limit, and every read carries the whole array. If growth has no natural bound, cap it (keep the latest 10 embedded) or move the rest to its own collection.

Duplicated values with unclear ownership. Copying authorName into articles is fine — until someone renames an author and half the copies never get updated. Duplicate deliberately, and name which collection holds the authoritative value and what updates the copies.

Mixed lifecycles. A document that combines a user’s profile, their settings, and their activity log mixes data that changes at completely different rates. Writes contend, and every reader pays for data it did not ask for.

Do the exercise for your own app: three most common reads, three most common writes, then documents. Collections come last, not first.