Contents
What to know about multi tenant SaaS applications?
When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your application. A tenancy model determines how each tenant’s data is mapped to storage. Your choice of tenancy model impacts application design and management.
This approach involves using the same database and the same set of tables to host multiple client’s data. So any given table can include records from multiple tenants stored in any order, and a Tenant ID (Client ID) column associates every record with the appropriate Tenant/Client.
How does shared database and shared schema architecture work?
The figure above shows how this approach manages data in the DB Tables. All Tenants/Clients will share the same set of tables, and a Tenant ID associates each tenant with the rows that it owns. This shared schema approach has the lowest hardware and backup costs, because it allows you to serve a large number of tenants/clients using one database.
How is data stored in a multi tenant environment?
While introducing a new SaaS product, the application has tenant data stored in separate databases plus an extra database for the list of tenants as well as data shared by every application [Generally called as Meta Database].
How is data distributed in a SaaS application?
Most SaaS applications access the data of only one tenant at a time. This access pattern allows tenant data to be distributed across multiple databases or shards, where all the data for any one tenant is contained in one shard. Combined with a multi-tenant database pattern, a sharded model allows almost limitless scale.
How are data stored in a multi tenant database?
Data: A multi-tenant database necessarily sacrifices tenant isolation. The data of multiple tenants is stored together in one database. During development, ensure that queries never expose data from more than one tenant. SQL Database supports row-level security, which can enforce that data returned from a query be scoped to a single tenant.
How does the RLS policy work in PostgreSQL?
Think of the RLS policy as a WHERE clause that filters the data for the tenant at the Database layer without having you to deal with the additional burden of placing the filtering logic in the application layer — how convenient. There are two ways by which you can achieve the data isolation across tenants.