{"dataset":{"id":"00000000-0000-0000-0000-000000000027","slug":"mongodb-best-practices","name":"MongoDB best practices","description":"Source-linked guidance on MongoDB fundamentals: the document data model, indexes, the aggregation pipeline, schema validation, and write concerns. Scoped to MongoDB; not a general database corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Write concerns for durable writes","sourceUrl":"https://www.mongodb.com/docs/manual/reference/write-concern/","text":"Write concern describes the level of acknowledgment requested from MongoDB for write operations to a standalone mongod, replica sets, or sharded clusters; in sharded clusters, mongos passes the write concern to the shards. For multi-document transactions, set the write concern at the transaction level and do not explicitly set it for individual write operations in the transaction. Replica sets and sharded clusters support a global default write concern — majority by default, configurable via setDefaultRWConcern, which requires a w field value — and operations without an explicit write concern inherit that default. The specification takes three fields: w requests acknowledgment that the write propagated to a specified number of mongod instances or instances with specified tags; j requests acknowledgment that the write has been written to the on-disk journal; wtimeout sets a time limit to prevent writes from blocking indefinitely. With w: \"majority\", the calculated majority of data-bearing voting members (the primary plus secondaries with votes greater than 0) must durably write the change to their local oplogs, and it is the default write concern for most MongoDB deployments. Scope: MongoDB. Reviewed October 4, 2026.","id":"mongodb-best-practices:Write concerns for durable writes","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Schema validation","sourceUrl":"https://www.mongodb.com/docs/manual/core/schema-validation/","text":"MongoDB uses a flexible schema model: by default, documents in a collection do not need the same fields or data types. After you establish an application schema, use schema validation to create rules for fields — allowed data types and value ranges — to prevent unintended schema changes and data type errors. Validation is most useful for an established application with a defined data structure, and rules are flexible: they need not cover every field unless your application requires it. Typical rules ensure an events collection's start_date stores only a date rather than a string, restrict accepted_credit_cards to values such as Visa, MasterCard, and American Express, or require gpa to be a positive floating-point number. Once rules are added, all document inserts must match them, and the validation level determines how rules apply to existing documents and updates. By default, MongoDB rejects any insert or update that would produce an invalid document; alternatively, you can configure it to allow invalid documents and log a warning. For Atlas deployments, validation can be implemented in the UI. Scope: MongoDB. Reviewed October 4, 2026.","id":"mongodb-best-practices:Schema validation","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"The aggregation pipeline","sourceUrl":"https://www.mongodb.com/docs/manual/core/aggregation-pipeline/","text":"An aggregation pipeline consists of one or more stages that process documents from a collection, a view, or a specially designed stage. Each stage performs an operation on its input documents — filtering, grouping, calculating values — and passes its output to the next stage; a stage need not output one document per input and may produce new documents or filter documents out. The same stage can appear multiple times in a pipeline, except for $out, $merge, and $geoNear. Pipelines run with db.collection.aggregate() do not modify documents in the collection unless the pipeline contains a $merge or $out stage, and you can also update documents with an aggregation pipeline through findAndModify. Expressions define how a stage processes each input document, built from constants, operators, and field path expressions; for example, { $add: [ 3, \"$inventory.total\" ] } adds 3 to the value at path inventory.total, with field paths prefixed by a dollar sign. On Atlas deployments, the Atlas UI can preview results at each stage. Scope: MongoDB. Reviewed October 4, 2026.","id":"mongodb-best-practices:The aggregation pipeline","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Indexes for query performance","sourceUrl":"https://www.mongodb.com/docs/manual/indexes/","text":"Indexes support efficient execution of queries: without one, MongoDB must scan every document in a collection, while an appropriate index limits the number of documents scanned. But adding an index has a negative performance impact on write operations — for collections with a high write-to-read ratio, indexes are expensive because each insert must also update the indexes. Index fields your application repeatedly queries: a single-field index suits lookups like employee ID, an index on an embedded document is used only by queries that specify the entire embedded document (queries on a field within it do not), and a compound index covers multiple fields such as item and quantity. MongoDB indexes use a B-tree data structure, store values ordered by value to support efficient equality matches and range operations, and can return sorted results using the index ordering. MongoDB creates a unique index on _id during collection creation, which cannot be dropped. Manage indexes with a driver method, the MongoDB Shell, or the Atlas UI, Atlas CLI, and Performance Advisor, which recommends indexes for slow queries and ranks them by impact. Scope: MongoDB. Reviewed October 4, 2026.","id":"mongodb-best-practices:Indexes for query performance","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"The document data model","sourceUrl":"https://www.mongodb.com/docs/manual/core/document/","text":"A document is the basic unit of data in MongoDB, and the object-oriented data model lets you structure data to mirror the object models in your codebase, eliminating the object-relational mapping required by relational databases. MongoDB stores records as BSON documents, a binary representation of JSON that contains more data types than JSON. Documents are field-and-value pairs, and a field value can be any BSON type, including embedded documents, arrays, and arrays of documents. Field names are strings: the _id field is reserved as a primary key, and its value must be unique in the collection, is immutable, and may be any type other than an array or regex; if _id contains subfields, their names cannot begin with a dollar sign. Field names cannot contain the null character, and each field name must be unique within a document — duplicate fields are unsupported and cause unexpected CRUD behavior even if an insert appears to succeed; the $objectToArray aggregation operator reveals duplicates. Use dot notation to access array elements by zero-based index and fields of embedded documents. Scope: MongoDB. Reviewed October 4, 2026.","id":"mongodb-best-practices:The document data model","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}