Introduction
Recently, I spent some time reading the book Building Multi-Tenant SaaS Applications by Tod Golding. In this post, I’ll summarize the key concepts from this book and share my thoughts on SaaS architecture.
SaaS Mindset
As Tod Golding states in the book, “At its core, SaaS is a business model.” This perspective is insightful and encourages us to think about SaaS with a bussiness mindset. Tod emphasizes that agility is a key advantage of the SaaS model. To understand why SaaS model offer better agility, We need know it’s difference with with the traditional installed software model. In the installed software model, the software is typical deployed on the customer’s server, often in various version, that require different management and operation support. While this model is good fit for some software providers and is suitable for specific situation. However, having different software versions across various environments greatly increases the complexity of the software upgrade and maintenance.
Installed Software Model, from Tod’s Book, redraw using Remdraw
Unlike the installed software model, the SaaS model uses a shared infrastructure to deliver the same software version to all tenants. With a unified version and shared infrastructure, software providers can manage, deploy, and operate their SaaS products collectively across different tenants. This operational efficiency accelerates business innovation, enabling softwate providers rapidly react to market and customer needs and seize new growth opportunities.
SaaS Model, from Tod’s Book redraw using Remdraw
In the SaaS model, it’s doesn’t matter if a tenant has dedicated resources or shared resources. The key point is that all tenants are running the same version of the software, which is the litmus test for SaaS model.
Shared vs Dedicated Infrastructure, from Tod’s Book redraw using Remdraw
However, Tod doesn’t explicitly discuss another important key factors drives the success of SaaS model in his book: economics of scale. Obviously, shared infrastucture among different tenants will bring the economics of scale.
Two Halves of SaaS
Just like when we talk about building, building a skyscraper isn’t same with building a house. The design and implementation of Saas architecture might be different in different suitation. However, Tod Golding provide a good framework to help us understand the SaaS architecture, he split the SaaS architecture into two aspects, the application plane and the control plane.
Two Halves of SaaS, from Tod’s Book redraw using Remdraw
Control Plane
The control plane is the backbone of a SaaS environment. It provides all the shared services that are used to manage, operate, and govern the multi-tenant environment. Think of it as the “management layer” of your SaaS application.
Key services in the control plane include:
- Onboarding Service: Automates the process of introducing new tenants into the system. When a new tenant signs up, the onboarding service provisions all the required resources, configures the tenant’s environment, creates the tenant admin user, and sets up billing. The goal is to make this process fully automated — a frictionless onboarding experience is essential for SaaS growth.
- Identity Service: Manages tenant and user identity, authentication, and authorization. In a multi-tenant environment, identity becomes more complex because every authenticated user must be associated with a tenant context. This tenant context is typically embedded in a JWT token and flows through the entire system, enabling downstream services to apply tenant-aware logic.
- Tenant Management Service: Stores and manages the metadata about each tenant — their tier, configuration, status (active, disabled, etc.), and any custom settings.
- Billing Service: Integrates with payment providers to handle subscription management, usage metering, and invoicing. Different tiers may have different pricing models (flat-rate, usage-based, or hybrid).
- Metrics & Analytics Service: Collects operational and business metrics across tenants. This includes tenant activity data, consumption patterns, resource utilization, and system health metrics. These insights drive critical business and architecture decisions.
The control plane is typically deployed separately from the application plane. It has its own lifecycle and is not multi-tenant in the same way — it manages all tenants collectively.
Application Plane
The application plane is where the actual business functionality lives. It’s the multi-tenant application that tenants interact with. The key challenge here is designing the application to serve multiple tenants simultaneously while maintaining isolation, performance, and security.
The application plane must be tenant-aware — every request flowing through the system carries a tenant context, and the application uses this context to ensure data isolation, apply tier-specific policies, and route requests to the appropriate resources.
Onboarding
Tod Golding emphasizes that onboarding is the front door of your SaaS. A well-designed onboarding process should be entirely automated and self-service. When a new tenant signs up, the system should:
- Create the tenant record in the tenant management service
- Provision the tenant’s identity — create the tenant’s identity provider configuration and admin user
- Provision infrastructure — if the tenant’s tier requires dedicated resources (e.g., a dedicated database or compute), those resources need to be created
- Configure billing — set up the subscription and payment method
- Apply tier policies — configure quotas, rate limits, and feature flags based on the tenant’s selected tier
The onboarding flow differs significantly between silo and pool deployment models. In a pool model, onboarding is relatively lightweight since tenants share existing infrastructure. In a silo model, onboarding may involve provisioning entirely new infrastructure stacks, which takes more time and orchestration.
Multi-Tenant Identity
Identity is one of the most critical and nuanced aspects of SaaS architecture. In a multi-tenant system, identity goes beyond simple “who is this user?” — it must answer “who is this user, and which tenant do they belong to?”
Tod Golding introduces the concept of tenant context flowing through every layer of the system. When a user authenticates, the identity provider issues a token (typically a JWT) that contains both the user identity and the tenant identity. This token propagates through API gateways, microservices, and data layers, enabling each component to make tenant-aware decisions.
Key considerations for multi-tenant identity:
- Tenant-per-identity-provider vs shared identity provider: Some SaaS systems create a separate user pool or identity realm per tenant (useful when tenants need their own federation or SSO), while others use a single identity provider with tenant as an attribute.
- Federated identity: Enterprise tenants often require integration with their own identity providers (e.g., Okta, Azure AD) via SAML or OIDC federation.
- Role-based access control (RBAC): Users within a tenant may have different roles (admin, editor, viewer), and the authorization system must enforce both tenant-level and role-level access policies.
Tenant Isolation
Tenant isolation is arguably the most important concern in multi-tenant architecture. If one tenant can access another tenant’s data or impact another tenant’s performance, the SaaS model fundamentally breaks.
Tod Golding distinguishes between two types of isolation:
Resource Isolation
Resource isolation is about ensuring that each tenant’s data and compute resources are logically or physically separated. There’s a spectrum of isolation strategies:
◀─── More Isolation Less Isolation ───▶
◀─── Higher Cost Lower Cost ───▶
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ SILO MODEL │ │ BRIDGE MODEL │ │ POOL MODEL │
│ │ │ │ │ │
│ ┌──┐ ┌──┐ ┌──┐ │ │ ┌──────────────┐ │ │ ┌──────────────┐ │
│ │T1│ │T2│ │T3│ │ │ │Shared Compute│ │ │ │Shared Compute│ │
│ │ │ │ │ │ │ │ │ └──────────────┘ │ │ └──────────────┘ │
│ │DB│ │DB│ │DB│ │ │ ┌──┐ ┌──┐ ┌──┐ │ │ ┌──────────────┐ │
│ │ │ │ │ │ │ │ │ │DB│ │DB│ │DB│ │ │ │ Shared DB │ │
│ │VM│ │VM│ │VM│ │ │ │T1│ │T2│ │T3│ │ │ │ T1,T2,T3 │ │
│ └──┘ └──┘ └──┘ │ │ └──┘ └──┘ └──┘ │ │ │ (tenant_id) │ │
│ │ │ │ │ └──────────────┘ │
│ Dedicated │ │ Shared compute, │ │ Everything │
│ everything │ │ Dedicated data │ │ shared │
└──────────────────┘ └──────────────────┘ └──────────────────┘- Silo isolation: Each tenant gets their own dedicated resources (separate databases, separate compute instances, or even separate accounts/VPCs). This provides the strongest isolation but at higher cost.
- Pool isolation: Tenants share the same resources (same database, same compute), and isolation is enforced through application-level logic (e.g., row-level security, tenant ID filtering in queries).
- Bridge model: A hybrid approach where some resources are siloed and others are pooled. For example, compute might be shared but each tenant gets their own database.
Data Partitioning
Data partitioning is one of the most consequential decisions in SaaS architecture because it’s extremely difficult to change later. Tod Golding presents three primary strategies:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────────┐
│ SILO │ │ BRIDGE │ │ POOL │
│ DB-per-Tenant │ │ Schema-per-T │ │ Shared Table │
│ │ │ │ │ │
│ ┌───┐ ┌───┐ │ │ ┌─────────────┐ │ │ ┌─────────────────┐ │
│ │DB │ │DB │ │ │ │ Database │ │ │ │ Database │ │
│ │ A │ │ B │ │ │ │ ┌─────────┐ │ │ │ │ │ │
│ └───┘ └───┘ │ │ │ │Schema A │ │ │ │ │ tenant_id | ... │ │
│ ┌───┐ ┌───┐ │ │ │ ├─────────┤ │ │ │ │ ────────────────│ │
│ │DB │ │DB │ │ │ │ │Schema B │ │ │ │ │ t-001 | ... │ │
│ │ C │ │ D │ │ │ │ ├─────────┤ │ │ │ │ t-002 | ... │ │
│ └───┘ └───┘ │ │ │ │Schema C │ │ │ │ │ t-001 | ... │ │
│ │ │ │ └─────────┘ │ │ │ │ t-003 | ... │ │
│ │ │ └─────────────┘ │ │ └─────────────────┘ │
│ Strong isolation│ │ Moderate │ │ App-level isolation │
│ High cost │ │ isolation │ │ Low cost │
└─────────────────┘ └─────────────────┘ └─────────────────────┘| Aspect | Silo (DB-per-Tenant) | Pool (Shared DB) | Bridge (Hybrid) |
|---|---|---|---|
| Data Isolation | Strong, physical separation | App-level (tenant_id filtering) | Moderate (schema-per-tenant) |
| Backup & Restore | Easy per-tenant | Complex, all tenants coupled | Per-schema possible |
| Performance Tuning | Tenant-specific tuning | One tenant’s growth impacts others | Some isolation possible |
| Infrastructure Cost | High (many databases) | Low (economies of scale) | Moderate |
| Management at Scale | Complex (thousands of DBs) | Simple, single DB | Moderate complexity |
| Cross-Tenant Analytics | Difficult | Easy, same tables | Requires cross-schema queries |
| Compliance | Easier for regulated industries | Concerns for sensitive data | Depends on what’s siloed |
Tiering Strategies
Tiers are at the heart of SaaS business strategy. Tod Golding makes a compelling argument that tiers are not just about pricing — they shape your entire architecture.
The answer to “which strategy to choose?” depends on your tenant profile, compliance requirements, and scale expectations. Tod suggests that many SaaS systems use a tiered approach: basic tenants go into the pool, premium tenants get siloed resources. This aligns isolation strategy with the business value of each tenant tier.
Tiered Data Partitioning Strategy
═════════════════════════════════
┌─────────────────────────────────────────────────────┐
│ SaaS Platform │
│ │
│ Basic & Standard Tenants Premium Tenants │
│ ┌───────────────────────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ Shared Pool DB │ │ DB │ │ DB │ │ DB │ │
│ │ ┌────┬────┬────┐ │ │ │ │ │ │ │ │
│ │ │ T1 │ T2 │ T3 │ │ │ T7 │ │ T8 │ │ T9 │ │
│ │ ├────┼────┼────┤ │ │ │ │ │ │ │ │
│ │ │ T4 │ T5 │ T6 │ │ │$$$ │ │$$$ │ │$$$ │ │
│ │ └────┴────┴────┘ │ └────┘ └────┘ └────┘ │
│ │ RLS enforced │ Dedicated per tenant │
│ └───────────────────────┘ │
└─────────────────────────────────────────────────────┘For PostgreSQL specifically, the Row-Level Security (RLS) feature is a powerful tool for pool-model data isolation. With RLS, the database itself enforces that queries can only see rows belonging to the current tenant, reducing the risk of application-level bugs leaking data.
Tier Architecture Impact
┌──────────────────────────────────────────────────────────────┐
│ │
│ BASIC STANDARD PREMIUM │
│ $9/mo $49/mo $299/mo │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Features │ │ Features │ │ Features │ │
│ │ # # . . │ │ # # # . │ │ # # # # │ │
│ ├──────────┤ ├──────────┤ ├──────────────┤ │
│ │ Pool │ │ Pool │ │ Silo │ │
│ │ Compute │ │ Compute │ │ Compute │ │
│ ├──────────┤ ├──────────┤ ├──────────────┤ │
│ │ Pool DB │ │ Pool DB │ │ Dedicated │ │
│ │ (shared) │ │ (shared) │ │ Database │ │
│ ├──────────┤ ├──────────┤ ├──────────────┤ │
│ │ 100 RPM │ │ 1K RPM │ │ Unlimited │ │
│ │ (rate) │ │ (rate) │ │ (dedicated) │ │
│ ├──────────┤ ├──────────┤ ├──────────────┤ │
│ │ Self- │ │ Email │ │ Dedicated │ │
│ │ service │ │ support │ │ support │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ │
│ RPM = Requests Per Minute │
└──────────────────────────────────────────────────────────────┘A typical SaaS might offer:
| Aspect | Basic Tier | Standard Tier | Premium Tier |
|---|---|---|---|
| Infrastructure | Pool (shared) | Pool (shared) | Silo (dedicated) |
| Performance | Shared, rate-limited | Shared, higher limits | Dedicated, guaranteed SLAs |
| Features | Core features | Extended features | Full features + custom |
| Support | Self-service | Email support | Dedicated support |
| Data Isolation | Shared database + RLS | Shared database + RLS | Dedicated database |
| Compliance | Standard | Standard | SOC2, HIPAA, etc. |
The important insight is that tiers directly influence architectural decisions: they determine deployment models, data partitioning strategies, isolation levels, and operational complexity. Your architecture must be flexible enough to support multiple tiers without maintaining separate codebases.
My Reflections
After reading Tod Golding’s book, here are some of my own takeaways:
SaaS is an Architectural Journey, Not a Destination
No one gets multi-tenant architecture perfect on day one. Most successful SaaS products start with a simpler architecture (often pool-based) and evolve toward more sophisticated patterns as they scale. The key is to build in the right abstractions early — particularly around tenant context propagation and data access — so that you can evolve your isolation and partitioning strategies without rewriting everything.
The Tension Between Simplicity and Isolation
There’s a fundamental tension in SaaS architecture: stronger isolation means more complexity and cost, while simplicity means more shared resources and higher risk. The art of SaaS architecture is finding the right balance for your specific context. Tiers are the mechanism that lets you offer different points on this spectrum to different customer segments.
Don’t Underestimate the Control Plane
It’s tempting to focus all engineering effort on the application plane — the features that customers see and use. But the control plane is what makes SaaS operationally viable. Without proper onboarding automation, tenant management, identity services, and observability, you’ll drown in operational overhead as you scale.
PostgreSQL as a Swiss Army Knife
For many SaaS startups, PostgreSQL is an excellent foundation. Its Row-Level Security, schema-per-tenant support, and extensibility make it well-suited for multi-tenant data partitioning. I discussed this in more detail in PostgreSQL is All You Need. Combined with connection pooling (e.g., PgBouncer) and proper indexing on tenant_id, PostgreSQL can scale surprisingly far before you need to consider more complex solutions.
Conclusion
Tod Golding’s book is an excellent resource for anyone building SaaS products. It provides a comprehensive framework for thinking about multi-tenant architecture — from business strategy to technical implementation. The key message I take away is that SaaS is not just about sharing infrastructure — it’s about building a unified, operationally efficient platform that can serve diverse tenants with different needs while maintaining agility and control.
If you’re building a SaaS product, I highly recommend reading this book. Even if you don’t adopt every pattern Tod describes, the mental models he provides will fundamentally change how you think about multi-tenant architecture.
References
- Tod Golding, Building Multi-Tenant SaaS Architectures, O’Reilly Media, 2024.
- Tod Golding’s YouTube Channel — excellent video content complementing the book.
- AWS SaaS Factory, SaaS Lens for the AWS Well-Architected Framework.
- Multi-tenant SaaS patterns — Microsoft Azure Architecture Center.