MongoDB in SaaS Platforms

Introduction

Multi-tenant SaaS platforms are the second-largest use of MongoDB, after content & commerce. The flexible schema lets every tenant evolve their data independently (custom fields, workflows, automations) without painful migrations — a near-impossible task in classical SQL.

The two dominant tenancy models are shared collection with tenantId (simple, dense, easy to scale) and collection-per-tenant or database-per-tenant (strong isolation, harder ops). Most SaaS pick the first and reach for the others only on regulated or whale customers.

Understanding the topic

SaaS data patterns on MongoDB:

• tenantId as the first field of every compound index — turns multi-tenant queries into single-shard hits.
• Per-tenant feature flags embedded in the tenant document.
• Custom fields stored as a sub-document custom: { ... } with optional schema validation.
• Plan & quota tracked on the tenant doc, enforced in middleware via $inc + bounded check.
• Atlas Global Clusters with zone sharding by tenantRegion for data residency.
• Per-tenant CSFLE keys when enterprise tenants demand cryptographic isolation.

Informative example

Multi-tenant query with mandatory tenantId guard in the repository:

class TicketRepo {
  constructor(private col: Collection<Ticket>, private tenantId: string) {}

  list(filter: Filter<Ticket> = {}) {
    // tenantId is ALWAYS the first part of the index and the query
    return this.col.find({ tenantId: this.tenantId, ...filter })
                   .sort({ createdAt: -1 }).limit(50).toArray();
  }
}

// Index that powers it
db.tickets.createIndex({ tenantId: 1, status: 1, createdAt: -1 });

Real-world use

HubSpot, Intercom, Forter, Asana-style projects and thousands of vertical SaaS run on multi-tenant MongoDB. Atlas's Online Archive moves cold tenant data to S3 transparently — keeps the working set hot and storage cost flat.

Best practices

• Enforce tenantId at the repository layer; never trust the app to add it.
• Put tenantId first in every compound index — cluster locality and shard targeting.
• Store custom fields under a single sub-document for clean projections and validation.
• Use Atlas Online Archive for tenants on cold/freemium plans — saves 70%+ storage.

Common mistakes

• One forgotten query without tenantId → instant cross-tenant data leak.
• Embedding everything (tickets inside tenant) — documents balloon past 16 MB.
• Per-tenant collections at large scale — metadata explosion crashes the catalog.