4 ms·
I'll take a typical context of a SaaS app, multi-tenant architecture. When it comes to store the data of your tenants, you have to decide between different appr
by hrbrtglm 13y ago
I'll take a typical context of a SaaS app, multi-tenant architecture.
When it comes to store the data of your tenants, you have to decide between different approaches which will impact the level of isolation of each tenant's data. I will not discuss the benefits and disadvantages of each because it clearly depends of your needs, security guidelines and sometimes regulations regarding your business, backup strategy, geo-isolation, sharding, etc ...
With MySQL, you can choose 2 way to architecture your data :
- the fully isolated way : each tenant has his own database.
- the shared way : all tenants share the same schema, you usually use a tenant_id column on tables to query your data adequately.
Some other RDBMS like PostgreSQL offer you a third way between the fully isolated a shared data system :
- all tenant access the same database but their data are stored on their own schema. It's up to you to decide if the tenants access their schema with the same database role (kind of user) or if you create a role for accessing solely their own schema.
Example :
App_DB
-- Public schema
-- tenant_id uuid
-- tenant_name (subdomain name for example)
-- etc ...
-- tenant (named after the public.tenant_id)
-- your application tables
-- tenant (named after the public.tenant_id)
-- your application tables
-- tenant (named after the public.tenant_id)
-- Some beta tables model for version n+1 of your app or whatever, you can add more table columns for this very tenant if he needs special features for example.
I hope it's non-documentation language but still english language :) (Need to improve my english and my writing skills)
- porker 13y agoThank you, that's really helpful :) Only last week I was sketching the database design (in MySQL) for a SaaS app, thinking how messy it was to add a tenant_id column and parameter onto every query...