postgresqlproductsaasdesign-decisions

Multi Tenant vs Single Tenant?


I am about to build a SAAS product using Rail and Postgres. I would like to know if I should follow schema level, sub-domain based multi tenancy or a single tenant application is good enough Architecture? My requirement has no dependability of data between clients hence schema based multi tenant architecture seems right to me. Could anyone please explain me further why it is good or bad with relevant explanation?


Solution

  • Here's a post from the creators of the Apartment gem suggesting they would not use schema-per-tenant approach in future.

    The end result of the above mentioned problems have caused us to mostly abandon our separate schemas approach to multi-tenancy. For all services we build going forward, we use a more traditional column scoped approach and have written our own wrappers that effectively mimic the per-request tenanting approach that Apartment gave us.

    If you are deploying to Heroku, there is a warning about schema-per-tenant affecting performance of the managed backup tool:

    The most common use case for using multiple schemas in a database is building a software-as-a-service application wherein each customer has their own schema. While this technique seems compelling, we strongly recommend against it as it has caused numerous cases of operational problems. For instance, even a moderate number of schemas (> 50) can severely impact the performance of Heroku’s database snapshots tool, PG Backups.

    For maximum data segregation a database-per-tenant approach is appropriate.

    For simplest operations, a tenant_id column per table can be used to scope your queries, and can be enforced with row level security policies.