Why should you care?

Wrong choice causes either huge documents or too many joins. Chat rooms (one room, many messages) almost always reference messages in their own collection.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// One author → many posts (reference + index)
db.users.insertOne({ _id: ObjectId("64a000000000000000000001"), username: "dev" })
db.posts.insertMany([
  { authorId: ObjectId("64a000000000000000000001"), title: "Indexing tips" },
  { authorId: ObjectId("64a000000000000000000001"), title: "Schema tips" }
])
db.posts.createIndex({ authorId: 1, createdAt: -1 })
db.posts.find({ authorId: ObjectId("64a000000000000000000001") })

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• The user is one document.
• Posts live in posts with authorId.
• An index on authorId makes “all posts by user” fast.
• This scales better than embedding thousands of posts inside the user.

Practice next

1. Insert one user and three posts.
2. Query posts by authorId.
3. Decide: would you embed comments if max 20 per post? Try both sketches.
4. Embed up to 5 recentOrderIds on the user for a dashboard.
5. Count posts with countDocuments({ authorId }).

Remember

One-to-many: embed small owned sets, reference large sets. Index the many-side foreign key. Model from how you query.

YouTube-like channel uploads

One channel has millions of videos — videos collection references channelId.

Outcome: Channel profile stays small; video queries paginate independently.