Every piece of data in MongoDB lives inside this three-level structure: a database contains collections, and each collection contains documents. Understanding this hierarchy makes every command in the rest of this course make sense.
A database is the top-level container — a single MongoDB server can host many databases, each isolated from the others. A typical project uses one database, e.g. blogApp or shopDB.
A collection is a group of related documents, roughly equivalent to a table in SQL — except a collection has no fixed schema by default. A users collection holds user documents, an orders collection holds order documents.
A document is a single record, stored as a set of field/value pairs — the MongoDB equivalent of a row. Documents in the same collection are not required to share the same fields, though in practice most documents in a collection do follow a consistent shape by convention.
// A document inside the "users" collection
{
_id: ObjectId("651f2a9e1c4a2b0012a4f8d1"),
name: "Rahul Verma",
email: "rahul@example.com",
age: 24,
isActive: true
}MongoDB documents look like JSON, but they are actually stored as BSON ("Binary JSON") — a binary-encoded format that adds data types JSON does not have natively, like dates, binary data, and the ObjectId type used for _id. You write and read data that looks like JSON; MongoDB handles the BSON conversion for you.
The _id field
Every document gets a unique _id field automatically if you don't supply one — MongoDB generates an ObjectId, a 12-byte value that is effectively guaranteed unique. This is the direct equivalent of a SQL primary key.