HOLIXORAMulti-tenancy is how most SaaS products serve multiple customers from a shared infrastructure. The choice of how to implement it — shared schema, separate schemas, or separate databases per tenant — is one of the most consequential early architectural decisions a SaaS product makes.
At Holixora, we made this decision separately for each product, because the right answer depends on factors that differ across the product portfolio.
The Three Models
Shared schema multi-tenancy puts all tenant data in the same tables, distinguished by a tenant ID column. It is the most cost-efficient at scale and the simplest to maintain, but it requires rigorous row-level security enforcement and creates the most severe blast radius if a data isolation bug is introduced.
Separate schemas per tenant keeps each customer in their own database schema within a shared database instance. It provides stronger logical isolation and makes tenant-specific migrations easier, at some additional operational complexity.
Separate databases per tenant gives maximum isolation — a bug in one tenant environment cannot affect another — but the cost scales linearly with tenant count and operational overhead grows significantly.
What We Chose and Why
Mercora uses a shared schema model with strict row-level security enforcement. The performance and cost characteristics at the scale we operate make this the right fit, and the security model has been designed from the ground up around the shared model.
Hanoman uses separate schemas because hotel data includes guest PII at a level where the additional isolation boundary is worth the operational trade-off.
The Cost of Getting It Wrong
Migrating from one multi-tenancy model to another after the product is in production is expensive. The data structures need to be rebuilt, the application code rewritten to match, and the migration executed without downtime. It is not impossible, but it is a significant engineering project.
The right time to make this decision correctly is before you have production data to migrate.