What it is
MongoDB is a document database. A database holds collections. A collection holds documents, which are JSON-like values stored as BSON (a binary format with a few extra types such as dates and object ids). You insert a document and later query by fields, including nested ones. There is no fixed table of columns, though you can and should enforce a schema validation so a missing email is an error rather than a surprise.
It is one kind of "NoSQL", a marketing word that hides differences. Redis is not MongoDB. A vector database is not MongoDB. The comparison that matters for most apps is with a relational database, in SQL versus NoSQL.
Why and when it is used
Use MongoDB when the thing you store is a document you usually read and write as a whole: a content item with varying attributes, a product catalogue entry, an event payload you do not want to normalise into twenty tables. Use it when your team already operates it and the access pattern matches.
Do not use it because a tutorial hated JOIN. Relational databases do joins well. Do not use it as a bucket of unrelated blobs with no indexes and then be surprised that queries scan. If your data is highly relational (orders, invoices, inventory counts that must not drift), PostgreSQL will push back in ways you want.
How it works
A client sends a query document: which fields must match, which fields to return, how to sort. Indexes on those fields keep it fast. Writes are to a primary. Replica sets copy data for failover. Sharding splits a collection across machines when one set of replicas is not enough; sharding is an operations project, not a configuration checkbox you flip on a Friday.
Transactions across documents exist and are slower and younger in people's mental models than a Postgres transaction. The comfortable Mongo pattern is to embed data that changes together in one document so one write is atomic. That embedding is the design. If you normalise everything into collections and join in the application, you rebuilt SQL without the constraints.
Technologies and dependencies
A MongoDB server or a managed cluster (Atlas is the vendor's cloud), a driver, and an index plan. ODM libraries (Mongoose is common in Node) add structure and can also hide queries. Prisma can target Mongo with limitations. Backups and a restore drill still exist. Schema validation rules belong in version control next to the app.
How to get started
- Run Mongo locally or in Docker. Create a database and a user that is not the admin.
- Insert three documents that share a shape and one that does not. Query them. Notice that the odd one still stored.
- Add schema validation that rejects the odd shape. Insert again and watch it fail.
- Create an index on the field you filter by. Explain the query.
- From the application, use the driver with parameters, not string-built queries.
- Write down whether you embed or reference related data, and why.
If you cannot explain the document boundary, you are not ready to pick embedding. Draw one document as it will look in production, including the arrays that might grow without limit.
Cautions and trade-offs
Unbounded arrays inside documents (a user document with every event ever) hit size limits and performance cliffs. Split those out. Indexes you forget are full scans, same as SQL. Case-sensitive field names mean Email and email are different bugs.
Managed clusters cost money when you leave them up. A local Docker container with no volume loses data. Security defaults have improved over the years and a database exposed to the internet with no auth is still a recurring incident; bind it to a private network. Finally, "schemaless" is not a requirement. Validate. The database will happily store your mistakes forever if you do not.