MongoDB is a document database. The unit of storage is a document: an ordered set of field/value pairs, written in a JSON-like form and stored in a binary format called BSON. Documents live in collections (roughly tables), and collections live in databases. Unlike a table row, a document can contain arrays and nested documents, so data that a relational design would spread over several tables can be stored, read and written as one unit.

This page targets the MongoDB 8.x line. Where a fact is version-sensitive it says so. All facts were checked against the MongoDB manual on 2026-10-31; the hands-on output comes from a real server run described in chapter 11.

mongosh is the MongoDB shell, a JavaScript environment. Every database operation is a method on a collection. The examples below were run against a real server (see chapter 11); shop is the database and orders and users the collections. Collections and databases are created implicitly on first write.

In a relational database you normalise first and then write queries. In MongoDB you start from the queries and updates the application performs and shape documents to serve them. The central decision is for each relationship: embed the related data inside the parent document, or reference it by storing its _id.

The three classic relationship shapes map to these answers: one-to-one and one-to-few usually embed; one-to-many (thousands) references from the many side, or embeds a small summary (extended reference, below); many-to-many stores arrays of ids on one or both sides.

MongoDB published a series of blog posts called Building with Patterns, and the manual now documents several of them under Schema Design Patterns. They are named solutions to recurring problems. Know the name, the problem and the trade-off; interviewers ask for exactly these.

Without an index MongoDB reads every document of the collection (a collection scan, COLLSCAN). An index is a B-tree of key values pointing to documents, kept sorted so equality, range and sort queries can walk a slice. Indexes cost memory and slow every write (each insert must update each index), so you want the few that serve your real queries. A collection can have at most 64 indexes and a compound index at most 32 fields.

explain shows how the server runs a query. Use the verbosity "executionStats": it actually runs the query and reports counts. The three numbers to read are **nReturned (documents returned), totalKeysExamined (index entries read) and totalDocsExamined** (documents fetched). A healthy query examines about as many keys and documents as it returns.

The run below used a collection of 100,000 orders with 1,000 customers, four statuses and a timestamp. The query is find({customerId: 42, status: "shipped"}).sort({createdAt: -1}), which returns 100 documents. These are real numbers from MongoDB 7.0.45 (the 8.x shell output has the same structure). The ms values are from one run on a laptop and only show direction.

Read the table as a story. With no index the server examined all 100,000 documents to return 100. The single-field index cut that to 100 keys and 100 documents but still sorted the 100 in memory (the SORT stage). The ESR index made the sort free. The projection made it covered. The last row is the lesson about prefixes: the query does not filter customerId, so the compound index cannot be used and the planner falls back to a collection scan.

find filters and projects. When you need grouping, joins, reshaping or computed output, use the aggregation pipeline: an array of stages, where each stage takes the documents from the previous one and passes new documents on. It is MongoDB's answer to GROUP BY, JOIN and subqueries.

A replica set copies the same data to every member, so it scales reads and availability but not total data size or write throughput of the primary. Sharding splits a collection across several replica sets (shards). Reach for it when data or write load no longer fits one replica set: not before, because a sharded cluster is much more work to operate.

Spring Data MongoDB maps Java classes to documents and offers two styles: the repository interface (MongoRepository) for CRUD and derived queries, and MongoTemplate for everything else (updates with operators, aggregations, bulk operations). Both sit on the MongoDB Java driver. The code on this page was compiled with javac against spring-boot-starter-data-mongodb 3.5.0, which brings Spring Data MongoDB 4.5.0 and the MongoDB Java driver 5.4.0. Spring Boot 4.0.0 brings Spring Data BOM 2025.1.0 and driver 5.6.1 (Spring Data MongoDB 5.x). Check the BOM for the Boot version you use.

• The Decimal128/BigDecimal mapping means money round-trips exactly, but the aggregation $sum over decimals is a decimal sum, so use BigDecimal fields for money, not double.
• Derived queries become real queries on your indexes: findByCustomerIdAndStatusOrderByCreatedAtDesc is the ESR query from chapter 5, so the matching @CompoundIndex matters.
• Use projections (interface or record projections) in repositories to avoid loading large documents when you need two fields.
• @Transactional methods get a session bound to the thread. The transaction manager uses the default write concern and read concern of the client unless you configure options.

The image tag mongo:8 exists on Docker Hub (pulled on 2026-10-31). Important note about the lab. On the machine used to write this page (Linux kernel 7.0), the mongo:8 and mongo:8.0 containers refused to start. The log says: MongoDB cannot start: Linux kernel versions 6.19 and newer has a known incompatibility with this version of MongoDB, referencing SERVER-121912. Version 7.0.45 started fine, so every real output on this page comes from **mongo:7.0 (server 7.0.45)**. On a host with an older kernel mongo:8 is what you want; the commands are identical. Output structure of explain is the same in 8.x, but exact numbers will differ on your machine.

The last line is real output from the 7.0.45 run and confirms the majority default. A host connecting from outside Docker must use a replica set host name it can resolve; the localhost:27017 member address above works for tools running inside the container.

Crisp answers for the questions that come up in interviews on MongoDB.

• Q: When would you choose MongoDB over a relational database?
  When the data is naturally document-shaped and read as a unit, the shape varies or evolves, and you need to scale horizontally. Choose relational when you need many ad hoc joins, strong cross-entity constraints and mature reporting tools. MongoDB also supports multi-document transactions, so "no transactions" is no longer a valid reason to reject it.
• Q: Embed or reference?
  Embed data that is read together, bounded and belongs to one parent. Reference data that is shared, large, unbounded or updated independently. Embedding gives one read and atomic updates; referencing avoids duplication and unbounded documents.
• Q: What is the maximum document size and why does it matter?
  16 MiB (BSON document size limit). It prevents one document from using excessive RAM or bandwidth, and it makes unbounded embedded arrays a design error. Larger files go to GridFS.
• Q: What is in an ObjectId?
  12 bytes: a 4-byte timestamp, a 5-byte per-process random value and a 3-byte counter. It is generated by the client, roughly time ordered, and unique without coordination. It is a poor shard key on its own because it increases monotonically.
• Q: Explain the ESR rule.
  Order compound index keys as Equality, Sort, Range. Equality fields first keep the rest ordered, the sort field next lets the index deliver the order, and range fields last so they do not break the sort.
• Q: How do you find out why a query is slow?
  Run explain("executionStats"). Compare nReturned to totalKeysExamined and totalDocsExamined, look for COLLSCAN and in-memory SORT, and add or reorder an index. Use the slow query log or profiler to find the queries.
• Q: What is a covered query?
  One answered entirely from an index: all filter and returned fields are in the index and _id is excluded unless indexed. Explain shows zero documents examined.
• Q: What does the default write concern guarantee?
  Since 5.0 the implicit default is w: "majority" (with an arbiter-related exception): the write is on a majority of data-bearing voting members and journaled before acknowledgement, so it survives a primary failure.
• Q: What can still be lost with w: 1?
  An acknowledged write that has not yet replicated is rolled back if the primary fails and a secondary without it is elected.
• Q: Describe a replica set election.
  When secondaries have not heard from the primary within electionTimeoutMillis (10 s by default), one calls an election and becomes primary with votes from a majority of voting members. Use an odd number of voters. Retryable writes let drivers ride through it.
• Q: Read concern levels?
  local (default) may be rolled back, available is for sharded low-latency reads, majority returns majority-committed data, linearizable is the strictest single-document read, snapshot is used in transactions.
• Q: How does sharding work and how do you choose a shard key?
  Data is split into ranges (chunks) by shard key across shards; mongos routes using config server metadata; the balancer moves chunks. A good key has high cardinality, even write distribution and matches the main query filter. Hashed keys even out writes; ranged keys support range queries; zones pin ranges to shards.
• Q: What is a jumbo chunk?
  A chunk bigger than the range size that cannot be split, usually because it contains one shard key value. It cannot be balanced; fix with a higher-cardinality shard key.
• Q: Can you change a shard key?
  Yes, since 5.0 by resharding to a new key, and you can refine a key by adding suffix fields. Resharding needs spare storage and careful planning.
• Q: Does MongoDB support ACID transactions?
  Yes, multi-document ACID transactions on replica sets (4.0) and sharded clusters (4.2) with snapshot isolation. They cost more than single-document writes, have a 60-second default lifetime and should not replace good schema design.
• Q: Name some schema design patterns.
  Bucket, subset, extended reference, computed, outlier, approximation, archive, schema versioning. Each solves a specific problem such as huge series, oversized working sets, repeated joins or hot aggregates.
• Q: What is the oplog?
  A capped collection on each replica set member recording idempotent write operations. Secondaries tail it to replicate, and change streams are built on it. Its size sets how long a secondary can lag or be offline without a full resync.
• Q: What are change streams used for?
  Real-time notification of data changes: cache invalidation, search index sync, event publishing. They are ordered, resumable via the resume token, and need a replica set or sharded cluster.
• Q: How does WiredTiger handle concurrency and durability?
  Document-level concurrency, an internal cache plus the OS cache, compression, and a write-ahead journal with periodic checkpoints. j: true or w: majority waits for the journal.
• Q: Why can $match placement matter in a pipeline?
  A leading $match can use an index and reduces documents for every later stage. The optimiser moves some filters earlier, but you should write it first anyway.
• Q: How do you make Spring @Transactional work with MongoDB?
  Declare a MongoTransactionManager bean, run against a replica set or sharded cluster, and keep transactions short.
• Q: Is a replica set a backup?
  No. It protects against node failure; a bad delete replicates. Take real backups (dump, snapshots or a managed service) and test restores.