MongoDB documents and collections compared with SQL tables

A relational database keeps data in tables made of rows and fixed columns. MongoDB keeps data in collections made of documents. A document looks like a JSON object: field names with values, and values can be strings, numbers, dates, arrays or whole nested objects.

The quickest way to get your bearings is a translation table:

• Database is still a database: a named container for collections.
• Table becomes a collection.
• Row becomes a document.
• Column becomes a field, but each document can have its own set of fields.
• Primary key becomes the _id field.
• JOIN is often replaced by putting related data inside the same document (embedding).

What a document looks like

{
  _id: ObjectId("665f1c2e9b1e8a3d4c2b1a01"),
  name: "Ada Lopez",
  email: "[email protected]",
  tags: ["admin", "beta"],
  address: { city: "Springfield", zip: "12345" },
  createdAt: ISODate("2026-01-15T09:30:00Z")
}

Internally MongoDB stores documents as BSON, a binary form of JSON that has more data types, such as dates and several number types. You reach into nested data with dot notation: "address.city" addresses the city field, and "tags.0" the first array element.

The _id field

• Every document has an _id. It must be unique within the collection and cannot be changed after the insert.
• If you insert a document without one, the driver generates an ObjectId for you.
• MongoDB automatically creates a unique index on _id when the collection is created.
• A single document can be at most 16 MiB. Larger files belong in GridFS or external object storage.

Flexible schema, not no schema

Documents in one collection do not have to share the same fields, and the same field can even hold different types in different documents. That makes early development fast, but your application still expects a certain shape. MongoDB lets you add schema validation to the parts of a document that need strict rules, while leaving the rest flexible.

Embedding versus references

The core rule in MongoDB data modeling is: data that is accessed together should be stored together. You have two tools:

• Embedding: put related data inside the parent document, for example the last few reviews inside a product. One read returns everything and no join is needed.
• References: store the related item’s _id and keep it in its own collection, for example the full review history. Use this when the related data is large, grows without limit, or is read separately.

// Embedded: the product page needs these every time
{ _id: 1, name: "Desk lamp", recentReviews: [ { user: "appuser", stars: 5 } ] }

// Referenced: older reviews live in their own collection
{ _id: 9001, productId: 1, user: "admin", stars: 4, text: "..." }

Design around your queries, not around a normalized diagram. If a page shows an order with its lines, embed the lines. If many orders point to one customer whose details change, reference the customer.

Replica sets: how MongoDB stays available

In production MongoDB normally runs as a replica set: a group of mongod processes that hold the same data.

• Exactly one member is the primary and receives all writes. It records every change in its operation log, the oplog.
• The other data-bearing members are secondaries. They copy the primary’s oplog and apply the same changes.
• If the primary cannot reach the others for longer than electionTimeoutMillis (10 seconds by default), an eligible secondary calls an election and becomes the new primary.
• An arbiter votes in elections but holds no data, so it adds no redundancy.
• Clients read from the primary by default. A read preference can send reads to secondaries, but replication is asynchronous, so those reads may return slightly old data.

// In mongosh, connected to a replica set member
rs.status()            // member states and health
db.hello()             // is this node primary? which hosts are in the set?

A replica set protects against a failed server, not against mistakes. A deleteMany run by accident is replicated to every member within moments, so you still need real backups.

When the document model fits

It fits well when records are naturally nested (a product with variants, a user with settings), when different records carry different attributes, and when most reads fetch one item with its details. It fits less well when your data is highly interconnected and you constantly combine many entities in ad hoc reports; a relational database is usually the simpler choice there.

Official documentation

• MongoDB Manual: Documents
• MongoDB Manual: Data modeling
• MongoDB Manual: Replication