MongoDB Multi-Tenancy
Parent: MongoDB Expert Knowledge · researched 2026-05-29T14:11:14.828Z· 15 sources · 10 concepts · skill mongodb-multi-tenancy
Multi-tenancy in MongoDB means a single deployment serves multiple customers (tenants) while keeping their data logically or physically isolated. The right architecture depends on the number of tenant
Overview
- Multi-tenancy in MongoDB means a single deployment serves multiple customers (tenants) while keeping their data logically or physically isolated. The right architecture depends on the number of tenants, their relative size, compliance requirements, and how much operational complexity you can absorb. [source]
When to use this skill
- Architecting a SaaS product on MongoDB Atlas [source]
- Choosing among shared-collection, database-per-tenant, or cluster-per-tenant isolation [source]
- Designing shard keys and zone sharding for data residency (GDPR, CCPA) [source]
- Implementing RBAC, connection pooling, or row-level security for multi-tenant workloads [source]
- Automating tenant lifecycle with the Atlas Admin API [source]
- Diagnosing noisy-neighbor or cross-tenant data leakage bugs [source]
- Setting up Atlas Projects for billing chargeback [source]
When NOT to use this skill
- Single-tenant applications - no isolation patterns needed; use standard MongoDB schema design [source]
- On-premises deployments without Atlas - some patterns (Atlas Projects, Data Federation, Atlas App Services Rules) are Atlas-only [source]
- Fewer than ~5 tenants with no growth plans - operational overhead of isolation patterns exceeds the benefit [source]
- Internal tooling where all users belong to the same trust boundary [source]
Hybrid (Production SaaS)
2. Shard Key Design and Zone Sharding
3. RBAC and Connection Security
- Model C: one DB user per tenant scoped to their database only [source]
- Collection-level RBAC alone does NOT prevent cross-tenant document reads - must combine with app-layer filter injection [source]
- CSFLE: per-tenant DEK, one MongoClient per tenant, autoEncryption.schemaMap [source]
- QE: shared client possible, autoEncryption.encryptedFieldsMap, supports range queries [source]
- Atlas Cedar Resource Policies (2025): org-wide enforcement of MFA, public access blocks, project-scoped tenant API keys [source]
4. Connection Pooling
- Shared pool (Model A): single MongoClient, maxPoolSize 100, all queries include tenantId [source]
- Per-tenant LRU pool (CSFLE): lru-cache with max:100, dispose closes evicted clients; maxPoolSize:5 per tenant; rule: LRU max × poolSize < cluster connection limit [source]
- Lambda/serverless: cache client in module scope outside handler; maxPoolSize:5, minPoolSize:0, maxIdleTimeMS:15000-30000; never call close() inside handler [source]
- Atlas Serverless: no pool config needed; scales to zero [source]
5. Schema Design
- tenantId in every document, every collection [source]
- All compound indexes: tenantId as leading field [source]
- Partial indexes for sparse tenant data [source]
- Model C: $jsonSchema collection validators per tenant DB [source]
- Model A: app-layer validation (Zod/Joi/Mongoose) [source]
- Repository pattern: structurally prepend tenantId to all find/aggregate/update/delete calls [source]
6. Atlas Projects as Hard Isolation
7. Billing and Cost Chargeback
- Projects = cost allocation units; tags (tenant, tier, cost-center) appear in invoice line items API [source]
- Shared clusters: instrument app-layer usage metrics; aggregate monthly [source]
- ADF for cross-tenant analytics: named virtual database (NOT $external); dedicated federated connection string [source]
8. Tenant Lifecycle
- Onboarding Model A: meta-store insert → create indexes → seed config → activate [source]
- Onboarding Model D: Atlas Admin API pseudocode: create project → cluster → wait IDLE → DB user → network access → store connection string [source]
- Offboarding: soft-delete → export/archive → batched delete (find _ids → deleteMany by _id, no limit option on deleteMany) → remove from meta-store [source]
- Backup schedule: /backup/schedule endpoint; separate /backupCompliancePolicy for governance floors [source]
- Migration: moveCollection = intra-cluster only; cross-cluster = mongosync or Atlas Live Migrate [source]
9. Row-Level Security Patterns
- Query filter injection (recommended): TenantScopedCollection middleware automatically appends tenantId to all operations [source]
- MongoDB views: read-only pre-filtered view per tenant; grant role on view not base collection [source]
- Atlas App Services rules: %%user.custom_data.tenantId - requires populating custom user data on provisioning; strongest guarantee (enforced before query runs) [source]
References
See Also
- [[mongodb-schema-design]] [[mongodb-sharding]] [[mongodb-atlas-expert]] [[mongodb-security-architecture]] [[mongodb-indexes-deep]] [[mongodb-atlas-iac]] [source]
Children
- Tenant Isolation Models (frontier)
- Shard Key Design for Multi-Tenancy (frontier)
- RBAC and Connection Security (frontier)
- Connection Pooling Strategies (frontier)
- Schema Design for Multi-Tenancy (frontier)
- Atlas Projects as Hard Isolation (frontier)
- Billing and Cost Chargeback (frontier)
- Tenant Lifecycle Operations (frontier)
- Row-Level Security Patterns (frontier)
- Multi-Tenancy Anti-Patterns (frontier)
Frontier under this node: Atlas Projects as Hard Isolation, Billing and Cost Chargeback, Connection Pooling Strategies, Multi-Tenancy Anti-Patterns, RBAC and Connection Security, Row-Level Security Patterns, Schema Design for Multi-Tenancy, Shard Key Design for Multi-Tenancy, Tenant Isolation Models, Tenant Lifecycle Operations