What Multi-Tenancy Actually Means
Multi-tenancy is an architectural pattern where a single software instance serves multiple customers, called tenants. Each tenant's data remains isolated from others, but they all share the same underlying infrastructure, database and codebase. Think of it as an apartment building: everyone lives under one roof, sharing utilities and structure, but each flat remains private.
The alternative is single-tenancy, where each customer gets their own dedicated instance. While this offers maximum isolation, it creates operational nightmares at scale. You'd need to deploy, monitor, patch and upgrade hundreds of separate systems. Multi-tenancy solves this by centralising operations whilst maintaining logical separation between tenants.
The Three Main Tenancy Models
The siloed approach gives each tenant their own database. You still run one application instance, but customer data lives in completely separate databases. This offers strong isolation and makes per-tenant backups straightforward, but it increases infrastructure costs and complicates migrations when you need to change the schema across hundreds of databases.
The pooled model stores all tenants in one database, with a tenant identifier column on every table. Queries filter by this ID to ensure customers only see their own data. This is the most cost-efficient approach and simplifies schema changes, but requires careful query design to prevent data leakage. Row-level security features in PostgreSQL can enforce isolation at the database layer.
The bridge model combines both strategies. High-value enterprise customers might get dedicated databases for compliance or performance reasons, whilst smaller customers share a pooled database. This hybrid approach offers flexibility but adds complexity to your data access layer, which now needs to route queries to different databases based on tenant characteristics.
Data Isolation and Security Considerations
Isolation failures represent your biggest risk in multi-tenant systems. A single bug that forgets to filter by tenant ID can expose one customer's data to another. This isn't theoretical—several high-profile SaaS companies have suffered exactly this failure. Defensive programming becomes essential: enforce tenant context at the framework level, use database row-level security as a second layer, and write integration tests that specifically verify isolation.
Encryption adds another dimension. Whilst encrypting data at rest and in transit protects against external threats, it doesn't prevent isolation bugs in your application code. Some regulated industries require tenant-specific encryption keys, which the pooled model can support through envelope encryption patterns. The siloed approach makes key-per-tenant simpler to implement but harder to rotate at scale.
- Always validate tenant context in middleware before queries execute
- Use database-level row security policies as defence in depth
- Implement comprehensive isolation tests in your CI pipeline
- Consider read replicas per tenant tier for performance isolation
- Log tenant context with every operation for audit trails
Billing Architecture and Metering
Your tenancy model affects how you measure and bill for usage. In a pooled database, you'll need to aggregate usage metrics by tenant ID—counting API calls, storage consumed, or features used. This metering data often lives in a separate analytics database to avoid impacting production performance. Time-series databases work well here because billing queries typically aggregate over periods.
Subscription management becomes more complex when you support multiple pricing tiers within the same system. Your access control layer needs to check both tenant identity and their subscription level before allowing operations. Feature flags tied to subscription tiers let you gradually roll out capabilities to higher-paying customers without deploying separate code.
Payment processing in multi-tenant systems usually follows a hub-and-spoke pattern. Each tenant gets their own customer record in your payment provider, but your application manages the relationship between tenant IDs and payment customer IDs. Webhook handlers must carefully validate which tenant an event belongs to before updating subscription status. Failed payments need tenant-specific retry logic and grace periods.
Scaling and Operational Realities
Multi-tenant systems scale differently than single-tenant ones. The pooled approach scales efficiently until you hit database limits, at which point you need to shard—splitting tenants across multiple database clusters. Sharding strategies might group tenants by creation date, geography, or size. The siloed model scales by adding databases, but you'll eventually need orchestration to manage hundreds of database instances.
Monitoring and observability require tenant-aware tooling. When response times spike, you need to know whether it affects all tenants or just one. Tagging metrics and logs with tenant IDs lets you isolate noisy neighbours—large customers whose usage patterns impact others. Some platforms implement per-tenant rate limiting and resource quotas to prevent any single customer from degrading service for everyone.
Schema migrations deserve special attention. With pooled databases, one migration runs against all tenant data simultaneously. Test thoroughly, because a failed migration affects everyone. The siloed approach lets you migrate tenant databases gradually, reducing risk but extending the migration window. YS Infomatics has built several multi-tenant platforms where migration strategy proved as important as the initial architecture choice, particularly for learning management and applicant tracking systems where uptime expectations vary by customer segment.