MongoDB Explained: Documents Instead of Tables

Introduction

MongoDB is the most popular document database: instead of tables of rows, it stores collections of documents — JSON-like objects that can hold nested data directly. If Postgres asks you to split your data into neat tables first, MongoDB lets you store it the way your application already thinks about it.

Documents that look like your code

A blog post with its comments, in MongoDB, is one document — no joins needed to read it:

{
  _id: ObjectId("..."),
  title: "Hello, MongoDB",
  author: "Sara",
  tags: ["databases", "beginner"],
  comments: [
    { author: "Ali", text: "Great intro!" },
    { author: "Waqas", text: "Clear and practical." }
  ]
}

Every document gets an _id automatically. Fields can be added or left out per document — one post can have a featured flag and another need not — which makes evolving your data model far less painful than altering tables. This flexibility is MongoDB's core appeal, especially early in a project when the shape of the data is still changing.

Embedding vs referencing: the key decision

MongoDB's central design question is whether to embed related data inside a document or reference it from another collection. The rule of thumb: embed data that is read together and rarely changes independently (comments inside a post), and reference data that is shared or changes on its own (authors, referenced by ID from many posts). Get this choice right and reads stay fast with no joins; get it wrong and you end up duplicating data that drifts out of sync.

When documents win — and when they don't

MongoDB shines for content, catalogs, user profiles, and rapidly changing data shapes, and it scales horizontally (across many servers) more naturally than most relational databases. But it trades away what Postgres guarantees: multi-document transactions were historically limited, and there are no foreign-key constraints enforcing relationships — your application must maintain them. For money and orders, that trade is usually wrong; for content and catalogs, it is usually right.

Takeaway

Documents that match your code's shape, flexible schemas that evolve without migrations, and one design question — embed or reference — that decides most of your performance. MongoDB is not "better" than Postgres; it is the right answer for a different shape of problem.

Originally published at https://practicaldevblog.blogspot.com/2026/10/mongodb-explained-documents-instead-of.html