MongoDB Document

MongoDB Document is an entity in which zero or more ordered field-value pairs are stored. A document is the basic unit of data in MongoDB, and documents are stored inside a MongoDB Collection.

In comparison to Relational Databases, a MongoDB document is roughly analogous to a record or row in a table. The difference is that a MongoDB document can store nested objects, arrays, and values with different BSON data types without requiring every document in the collection to have the exact same fields.

Document in MongoDB follows BSON Specifications. BSON is a binary encoded serialization format for JSON-like documents. MongoDB uses BSON so that documents can store JSON-style data along with additional data types such as ObjectId, Date, Decimal128, and binary data. You can also refer to MongoDB’s official Documents page and BSON Types reference for the supported document model.

A document can have documents nested in them. MongoDB Documents are the building blocks of a MongoDB Collection. A collection can contain many documents, and each document usually represents one real-world item such as a user, order, product, course, invoice, or log entry.

We shall learn following topics in this tutorial :

MongoDB Document Operations

Following operations could be performed on MongoDB Documents.

The common document workflow is create, read, update, and delete. In MongoDB shell examples, these actions are usually written with methods such as insertOne(), find(), updateOne(), and deleteOne().

</>
Copy
db.users.insertOne({ name: "Midhuna", age: 23 })
db.users.find({ age: 23 })
db.users.updateOne({ name: "Midhuna" }, { $set: { place: "New York" } })
db.users.deleteOne({ name: "Midhuna" })

Structure of MongoDB Document

Following is structure of a Document in MongoDB:

</>
Copy
{
	field1:value1;
	field2:value2;
	.
	.
	fieldN:valueN;
}

Document can contain N number of field-value pairs.

The values can have any datatype that is supported by BSON specification.

The above block shows the idea of field-value pairs. In actual MongoDB shell usage, a document is written like a JavaScript object literal, and field names are commonly written as strings or valid unquoted identifiers. The following example shows a valid document shape that can be inserted into a collection.

</>
Copy
{
  name: "Midhuna",
  age: 23,
  place: "New York",
  hobbies: ["Singing", "Reading Books"]
}

When MongoDB stores this document, it stores it as BSON. If you do not provide an _id field, MongoDB automatically adds one. The _id value is unique within the collection and acts as the primary identifier for the document.

{
  _id: ObjectId("64c7f2a7b5a4e61f0c40b901"),
  name: "Midhuna",
  age: 23,
  place: "New York",
  hobbies: ["Singing", "Reading Books"]
}

MongoDB Document Fields and Values

A MongoDB document is made of fields and values. The field name describes what the value represents, and the value stores the actual data. A value can be a simple value such as a string or number, or a complex value such as an array or embedded document.

Document partExampleMeaning
Field namenameThe key used to identify a value in the document.
String value"Midhuna"Text data stored in a field.
Number value23Numeric data such as age, score, quantity, or price.
Array value["Singing", "Reading Books"]A list of values stored under one field.
Embedded document{ name: "Akash", age: 25 }A nested document stored inside another document.
Identifier field_idThe unique identifier for a document in a collection.

Simple MongoDB Document

Following is a simple Document with field-value pairs

</>
Copy
{
	name: "Midhuna",
	age: 23,
	place: "New York",
	hobbies: ["Singing", "Reading Books"]
}

This document has four fields: name, age, place, and hobbies. The hobbies field is an array, so it can store multiple values in one field.

Sample MongoDB Document with Nested Data

Lets see a Document containing other documents nested in.

</>
Copy
{
	name: "Midhuna",
	age: 23,
	place: "New York",
	hobbies: ["Singing", "Reading Books"]
	spouse: {
		name: "Akash",
		age: 25
	}
}

The spouse field stores another document inside the main document. This is called an embedded document or nested document. Embedded documents are useful when the nested data is usually read together with the parent document.

The sample above keeps the original tutorial structure. In actual inserts, remember to separate fields with commas. A corrected shell-ready version is shown below.

</>
Copy
{
  name: "Midhuna",
  age: 23,
  place: "New York",
  hobbies: ["Singing", "Reading Books"],
  spouse: {
    name: "Akash",
    age: 25
  }
}

BSON Data Types in MongoDB Documents

MongoDB documents are similar to JSON documents, but BSON supports more data types than plain JSON. This is one reason MongoDB can store application data such as dates, object identifiers, binary data, and decimal values without converting everything into strings.

BSON typeExample in a documentCommon use
String{ name: "Midhuna" }Names, labels, descriptions, and text values.
Number{ age: 23 }Counts, scores, quantities, and measurements.
Boolean{ active: true }Yes/no or true/false values.
Date{ createdAt: new Date() }Created time, updated time, expiry time, and event time.
ObjectId{ _id: ObjectId("...") }Document identifiers and references.
Array{ hobbies: ["Singing", "Reading Books"] }Lists of values inside a document.
Embedded document{ address: { city: "New York" } }Related data stored inside the same document.

MongoDB Document Design: Embed or Reference

MongoDB document design depends on how the application reads and updates the data. A common rule is to embed data that belongs to the parent document and is usually read together, and to reference data when it is shared across many documents or grows independently.

  • Embed related details when the child data is small and naturally belongs to one parent, such as an address inside a user document.
  • Use references when the related data is large, reused in many places, or updated separately, such as a product referenced by many orders.
  • Avoid documents that grow without limit, such as storing every activity log forever inside one user document.
  • Model for query patterns, because document structure should make the common reads and writes simpler.

The official MongoDB Data Modeling documentation explains these design choices in more detail.

MongoDB Document Example for an Order

The following order document shows a practical document structure with simple fields, embedded customer data, an array of item documents, and date values.

</>
Copy
{
  orderNumber: "ORD-1001",
  orderDate: new Date("2026-01-15T10:30:00Z"),
  status: "paid",
  customer: {
    name: "Midhuna",
    email: "midhuna@example.com"
  },
  items: [
    {
      sku: "BK-101",
      title: "MongoDB Basics",
      quantity: 1,
      price: 450
    },
    {
      sku: "NT-210",
      title: "Notebook",
      quantity: 2,
      price: 80
    }
  ],
  totalAmount: 610
}

This structure is suitable when the application often reads an order together with its customer snapshot and line items. If customer details need to be shared and updated across many orders, store a customerId reference instead of embedding the full customer details in every order.

Insert and Query a MongoDB Document

To try a document in mongosh, select a database, insert the document, and query it from the collection.

</>
Copy
use tutorialkart

db.users.insertOne({
  name: "Midhuna",
  age: 23,
  place: "New York",
  hobbies: ["Singing", "Reading Books"]
})

db.users.find({ name: "Midhuna" })

The insert operation stores the document in the users collection. The query operation searches for documents where the name field has the value "Midhuna".

Common Mistakes with MongoDB Documents

  • Writing invalid object syntax: separate fields with commas when writing documents in mongosh or application code.
  • Ignoring the _id field: every document needs a unique _id in its collection. MongoDB creates it automatically if you do not provide one.
  • Embedding unlimited arrays: arrays that keep growing can make documents difficult to manage. Consider a separate collection for large or unbounded data.
  • Copying relational table design directly: MongoDB documents should be designed around application queries, not only around normalized table structures.
  • Storing dates as plain strings: use date values when you need date comparisons, sorting, or range queries.

Editorial QA Checklist for MongoDB Document Tutorial

  • Check that examples explain documents as field-value pairs stored inside MongoDB collections.
  • Verify that newly added document examples use valid comma-separated shell syntax.
  • Confirm that BSON-specific types such as ObjectId and Date are not described as plain JSON-only values.
  • Make sure embedded document examples explain when nested data is useful.
  • Review references to rows and records so they are described as analogies, not exact equivalents.

MongoDB Document FAQs

What is a MongoDB document?

A MongoDB document is a data record made of field-value pairs. It is stored in a collection and uses BSON format internally.

How is a MongoDB document different from a row in SQL?

A SQL row follows the fixed columns of a table. A MongoDB document is more flexible and can include nested documents, arrays, and fields that may differ from another document in the same collection.

Does every MongoDB document need an _id field?

Yes. Every document in a collection has an _id field. If you do not provide it during insert, MongoDB adds one automatically.

Can a MongoDB document contain another document?

Yes. A MongoDB document can contain embedded documents. This is useful when related data is commonly read together with the parent document.

Is a MongoDB document the same as JSON?

No. MongoDB documents look similar to JSON, but MongoDB stores them as BSON. BSON supports additional data types such as ObjectId, Date, and binary data.

Conclusion

In this MongoDB Tutorial, we have learnt about MongoDB Documents, its structure with samples and the operations that could be performed on them. A MongoDB document is a BSON-based field-value structure stored in a collection. It can contain simple values, arrays, and nested documents, so the document structure should be planned according to how the application stores, reads, and updates data.