Multi-tenancy patterns in Firebase - Mini Project: Build & Apply

Implementing Multi-Tenancy Patterns in Firebase

📖 Scenario: You are building a cloud backend using Firebase for a software service that supports multiple companies (tenants). Each company should have its own isolated data in the database to keep information private and secure.

🎯 Goal: Build a Firebase Firestore data structure and security rules that implement a simple multi-tenancy pattern. You will create tenant-specific data collections, configure a tenant ID variable, write a query to fetch tenant data, and finalize Firestore security rules to restrict access to only the tenant's own data.

📋 What You'll Learn

Create a Firestore collection named companies with two tenant documents: tenantA and tenantB

Add a configuration variable currentTenantId set to tenantA

Write a Firestore query to get all projects documents under the current tenant's subcollection

Add Firestore security rules to allow read and write access only to documents under the authenticated user's tenant ID

💡 Why This Matters

🌍 Real World

Multi-tenancy is common in SaaS applications where multiple companies share the same backend but need data isolation for security and privacy.

💼 Career

Understanding multi-tenancy patterns and security rules in Firebase is essential for cloud engineers and backend developers building scalable, secure multi-tenant applications.

1

Create Firestore tenant data structure

Create a Firestore collection called companies with two documents named tenantA and tenantB. Each tenant document should have a subcollection called projects with one document each: project1 for tenantA and project2 for tenantB. Use the following data for the projects: { name: 'Project Alpha' } for project1 and { name: 'Project Beta' } for project2.

Firebase

// Your code here to define Firestore data structure for tenants and projects

Hint

Think of companies as a collection. Each tenant like tenantA is a document. Inside each tenant document, create a projects subcollection with project documents.

2

Add tenant configuration variable

Create a variable called currentTenantId and set it to the string 'tenantA'. This variable will represent the tenant currently logged in or active.

Firebase

const companies = {
  tenantA: {
    projects: {
      project1: { name: 'Project Alpha' }
    }
  },
  tenantB: {
    projects: {
      project2: { name: 'Project Beta' }
    }
  }
};

// Define currentTenantId variable
// Your code here

Hint

This variable holds the tenant ID string exactly as 'tenantA'.

3

Write Firestore query for tenant projects

Write a Firestore query using the currentTenantId variable to get all documents from the projects subcollection under the current tenant in the companies collection. Use the Firestore JavaScript SDK syntax with collection and getDocs. Store the query reference in a variable called tenantProjectsQuery.

Firebase

const companies = {
  tenantA: {
    projects: {
      project1: { name: 'Project Alpha' }
    }
  },
  tenantB: {
    projects: {
      project2: { name: 'Project Beta' }
    }
  }
};

const currentTenantId = 'tenantA';

// Write Firestore query to get projects for currentTenantId
// Your code here

Hint

Use collection(db, 'companies', currentTenantId, 'projects') to target the projects subcollection for the current tenant.

4

Add Firestore security rules for tenant isolation

Write Firestore security rules that allow read and write access only if the authenticated user's request.auth.token.tenantId matches the tenant ID in the document path. The rules should apply to documents under companies/{tenantId}/projects/{projectId}. Use allow read, write: if request.auth != null && request.auth.token.tenantId == tenantId;.

Firebase

import { collection, getDocs } from 'firebase/firestore';
import { db } from './firebaseConfig';

const companies = {
  tenantA: {
    projects: {
      project1: { name: 'Project Alpha' }
    }
  },
  tenantB: {
    projects: {
      project2: { name: 'Project Beta' }
    }
  }
};

const currentTenantId = 'tenantA';

const tenantProjectsQuery = collection(db, 'companies', currentTenantId, 'projects');

// Add Firestore security rules below
// Your code here

Hint

Security rules must check that the authenticated user's tenant ID matches the tenantId in the document path.

Practice

1. What is the main purpose of multi-tenancy in Firebase applications?

easy

A. To allow multiple users to share the same app while keeping their data separate

B. To increase the speed of database queries

C. To reduce the cost of Firebase hosting

D. To enable offline data access for users

Solution

1. Step 1: Understand multi-tenancy concept

   Multi-tenancy means many users use one app but their data stays separate.

2. Step 2: Identify the purpose in Firebase context

   Firebase apps use multi-tenancy to keep user data isolated while sharing the app.

3. Final Answer:

   To allow multiple users to share the same app while keeping their data separate -> Option A

4. Quick Check:

   Multi-tenancy = separate data for shared app [OK]

Hint: Multi-tenancy means shared app, separate data [OK]

Common Mistakes:

• Confusing multi-tenancy with performance optimization
• Thinking multi-tenancy is about offline access
• Assuming multi-tenancy reduces hosting costs

2. Which Firestore data structure is best for separating tenant data in a multi-tenant Firebase app?

easy

A. A single collection with tenant ID as a field in each document

B. Separate collections for each tenant grouped by tenant ID

C. One document per tenant with all data nested inside

D. Storing all tenant data in one document without tenant ID

Solution

1. Step 1: Review Firestore data organization

   Firestore uses collections and documents to organize data.

2. Step 2: Choose best pattern for tenant separation

   Grouping data by tenant ID in separate collections keeps tenant data isolated and easier to secure.

3. Final Answer:

   Separate collections for each tenant grouped by tenant ID -> Option B

4. Quick Check:

   Tenant data separated by collections = Separate collections for each tenant grouped by tenant ID [OK]

Hint: Use collections grouped by tenant ID for clear separation [OK]

Common Mistakes:

• Putting all tenant data in one document
• Not using tenant ID to separate data
• Using a single collection without grouping

3. Given this Firestore security rule snippet for multi-tenancy:

match /tenants/{tenantId}/data/{docId} {
  allow read, write: if request.auth.token.tenant == tenantId;
}

What happens if a user with tenant ID 'tenantA' tries to read data from 'tenantB'?

medium

A. Access is granted because tenant IDs are ignored

B. Access is granted only for read but not write

C. Access is denied only if the document does not exist

D. Access is denied because tenant IDs do not match

Solution

1. Step 1: Understand the security rule condition

   The rule allows access only if the user's tenant ID matches the tenantId in the path.

2. Step 2: Apply the condition to the user and requested tenant

   User's tenant ID is 'tenantA' but tries to access 'tenantB' data, so condition fails.

3. Final Answer:

   Access is denied because tenant IDs do not match -> Option D

4. Quick Check:

   Tenant ID mismatch blocks access [OK]

Hint: Tenant ID in token must match path tenant ID [OK]

Common Mistakes:

• Assuming access is granted without tenant ID check
• Thinking read access is allowed but write is denied
• Ignoring tenant ID in security rules

4. You wrote this Firestore rule for multi-tenancy:

match /tenants/{tenantId}/data/{docId} {
  allow read, write: if request.auth.token.tenantId == tenantId;
}

But users report access errors. What is the likely problem?

medium

A. The token field name is incorrect; it should be 'tenant' not 'tenantId'

B. The path variable 'tenantId' is not defined in the rule

C. Firestore does not support tenant-based security rules

D. The rule allows access to all tenants without restriction

Solution

1. Step 1: Check token field name in the rule

   The rule uses 'request.auth.token.tenantId' but the token field is usually 'tenant'.

2. Step 2: Understand impact of wrong token field

   If the token field name is wrong, the condition always fails, causing access errors.

3. Final Answer:

   The token field name is incorrect; it should be 'tenant' not 'tenantId' -> Option A

4. Quick Check:

   Correct token field name fixes access [OK]

Hint: Match token field name exactly in rules [OK]

Common Mistakes:

• Using wrong token field name
• Assuming Firestore ignores token field names
• Not defining path variables correctly

5. You want to design a Firebase app supporting multiple tenants with isolated data and secure access. Which combination of patterns is best?

hard

A. Use a single Firestore collection for all tenants and filter data in the app code

B. Use Firebase Realtime Database instead of Firestore for multi-tenancy

C. Create separate Firestore collections per tenant and enforce tenant ID checks in security rules

D. Store all tenant data in one document and use client-side filtering for access control

Solution

1. Step 1: Evaluate data separation methods

   Separate collections per tenant keep data isolated and easier to manage.

2. Step 2: Apply security best practices

   Security rules must check tenant ID to prevent unauthorized access.

3. Step 3: Compare options

   Create separate Firestore collections per tenant and enforce tenant ID checks in security rules combines data separation and security rules, ensuring isolation and protection.

4. Final Answer:

   Create separate Firestore collections per tenant and enforce tenant ID checks in security rules -> Option C

5. Quick Check:

   Separate collections + security rules = best multi-tenancy [OK]

Hint: Combine data separation with security rules for best isolation [OK]

Common Mistakes:

• Relying on client-side filtering only
• Using single collection without security rules
• Choosing Realtime Database without need