🔹 Who is Involved?
- Provider: Salesforce (One of the world’s largest SaaS companies, built on a proprietary multi-tenant architecture).
- Clients (Tenants): Coca-Cola, Amazon, Toyota, Spotify, and thousands of other businesses using Salesforce CRM.
1️⃣ Salesforce’s Multi-Tenancy Model: Shared Database, Shared Schema
🔍 How Salesforce Stores Data
Salesforce serves thousands of businesses from a single database instance but ensures strict tenant isolation using:
-
Tenant Identifiers (
organization_id
) – Uniquely identifies each company. - Metadata-Driven Architecture – Each customer’s configurations (fields, workflows) are stored as metadata instead of separate tables.
- Row-Level Security (RLS) & Object-Level Security (OLS) – Ensures users can only access their company’s data.
🔹 Example: How Customer Data is Stored in Salesforce
Shared Table with Tenant Identifier (organization_id
)
CREATE TABLE contacts (
id SERIAL PRIMARY KEY,
organization_id INT NOT NULL, -- Tenant Identifier
name VARCHAR(255),
email VARCHAR(255),
created_at TIMESTAMP DEFAULT NOW()
);
Fetching Data for a Specific Tenant (Customer Organization)
SELECT * FROM contacts WHERE organization_id = 456; -- Only fetch contacts for Org 456
2️⃣ How Salesforce Handles Scaling for Millions of Tenants
🔹 Key Technologies Used
✅ Proprietary Multi-Tenant Database (Force.com Platform)
✅ Row-Level Security (RLS) – Ensures strict data isolation.
✅ Metadata-Driven Architecture – Instead of creating separate tables for each company, Salesforce stores configurations as metadata.
✅ Horizontal Partitioning (Sharding) – Distributes large customers across different servers.
🔹 Example: Metadata-Driven Multi-Tenancy
Instead of creating a custom_fields
table per tenant, Salesforce stores custom fields dynamically in metadata:
{
"organization_id": 456,
"custom_field_name": "Customer_Type",
"custom_field_value": "Premium"
}
This means each company can define its own custom fields, workflows, and reports without changing the core database structure.
3️⃣ How Salesforce Ensures Data Isolation & Security
🔹 1. Row-Level Security (RLS)
Salesforce ensures that a tenant (company) can only access its own records:
CREATE POLICY tenant_isolation
ON contacts
FOR SELECT
USING (organization_id = current_setting('app.current_organization')::int);
Before queries run, Salesforce sets the current tenant:
SET app.current_organization = 456;
SELECT * FROM contacts; -- Fetches only Org 456’s contacts
🔹 2. Object-Level Security (OLS) & Field-Level Security (FLS)
Salesforce also restricts access to specific objects (tables) and fields based on user roles.
✅ Example: Role-Based Access
- Admins can view all customer records.
- Sales reps can only view their assigned customers.
SELECT * FROM contacts WHERE assigned_sales_rep = 'John Doe';
✅ Example: Hiding Sensitive Fields
- Field-level security ensures only authorized users can access sensitive data.
SELECT name, email FROM contacts; -- Omits sensitive fields like `ssn`
4️⃣ Why Salesforce Uses a Shared Schema Instead of Separate Databases
Approach | Isolation | Performance | Cost | Complexity |
---|---|---|---|---|
Shared Schema (Salesforce’s Model) | Medium | High | Low | Low |
Separate Databases per Tenant | High | Medium | High | High |
Salesforce’s Reasoning:
- ✅ Shared schema allows fast retrieval of multi-tenant data.
- ✅ Metadata-driven architecture makes customization easy.
- ✅ Security rules (RLS, OLS, FLS) ensure tenant isolation.
- ✅ Sharding helps distribute large customers across different database clusters.
🔹 Final Takeaways
✔️ Salesforce uses a shared database with row-level security & metadata-driven multi-tenancy.
✔️ Customers customize their CRM setup without altering the database structure.
✔️ Sharding & indexing ensure scalability for large enterprises like Coca-Cola & Amazon.
🚀 This approach allows Salesforce to serve thousands of businesses while keeping their data secure and isolated.
Would you like a deep dive into another SaaS example like Shopify or QuickBooks? 😊
Top comments (0)