Sources and further reading

Cross-checked against the official manual plus the following. Where guidance conflicted, the MongoDB documentation won.

Data modeling

• MongoDB Schema Design Best Practices for 2026, DbSchema
• How to Choose Between Embedding and Referencing in MongoDB
• How to Design MongoDB Schemas for Real-World Applications
• MongoDB schema design: 6 patterns every developer should master
• MongoDB Data Modeling: Schema Design Patterns and Best Practices, tutorialQ

Multi-tenancy

• Build a Multi-Tenant Architecture, MongoDB Atlas docs
• Multi-tenant Architecture with Moveable Collections, MongoDB manual
• Multi-tenancy and MongoDB, Mike LaSpina
• How to Model a Multi-Tenant Application Schema in MongoDB
• Fine-Tuning MongoDB for Multi-Tenant SaaS Applications, Reintech

The index-ceiling caution for database-per-tenant comes from the Atlas guidance above, which puts the practical limit in the low thousands of databases.

Indexing and scaling

• Performance Best Practices: Indexing, MongoDB
• Optimizing MongoDB Compound Indexes: the ESR Rule, Alex Bevilacqua
• How to Use the ESR Rule for Compound Index Design
• MongoDB Indexing Best Practices, DataCamp
• Choose a Shard Key, MongoDB manual
• Shard Keys, MongoDB manual
• 10 MongoDB anti-patterns that cost millions, Mydbops

Security

• Guide to Database Security, MongoDB
• Securing Your MongoDB Database: Essential Best Practices, Percona
• MongoDB Security 101, DataCamp
• Top 5 MongoDB Security Best Practices, CloudDefense
• MongoDB Security: Hardening Access, Authentication, Encryption, and Auditing

Which claims here are opinion

Worth arguing with, because they are judgement rather than documentation:

• Shared collections as the default for a consultancy. Defensible for a

portfolio of similar apps; the wrong call if most clients are regulated enterprises who will demand isolation in the contract.

• Do not shard early. Strongly held and occasionally wrong. If a workload is

known to be write-saturating from day one, designing the shard key up front is cheaper than resharding later.

• 404 rather than 403 for another tenant's object. A deliberate trade of

debuggability for a smaller information leak.

• Do not mirror _id into a separate id field. Common in practice and

usually a habit carried from SQL. The cost is a second unique index per collection.

• Keep documents under about 100KB. A rule of thumb, not a documented limit.

The real limit is 16MB and the real constraint is whether the working set fits in RAM.

• Transactions are a smell if you need them everywhere. True for

document-oriented modeling, and unhelpful if the domain is genuinely relational, in which case the honest answer may be that this data belongs in Postgres.