nestonexStart a project Should each tenant get its own database, or share one with a tenant column?
It depends what the data is worth. A shared database with a tenant column is cheaper to run and far simpler to migrate, but one missing filter leaks across customers. A database per tenant gives hard isolation and costs you provisioning, migrations across many databases, and real per-tenant overhead.
Migrations, mostly. A schema change that was one operation is now one operation per tenant, and it has to be resumable, because a migration that fails halfway across two hundred databases leaves you in a mixed-version state.
Then there is connection pooling, which does not divide neatly across many databases, and a per-tenant cost floor that makes small customers uneconomic. Provisioning has to be automatic or onboarding becomes a manual job.
None of this is hard. It is all just more, and it compounds with tenant count in a way shared tenancy does not.
Schema-per-tenant inside one database is a common compromise: better isolation than a shared table, cheaper than separate instances, though migrations still multiply.
Row-level security is the other. The database enforces the tenant filter rather than trusting application code to remember, which removes the most common failure while keeping one database. For many products that is the right answer, and it is considerably cheaper than full separation.
Three things. How sensitive the data is, and what a cross-tenant leak would mean commercially rather than technically. Whether any contract or regulation requires separation outright. And the shape of your tenant base, because a handful of large customers economically supports dedicated infrastructure in a way a long tail of small ones does not.
What should not decide it is which sounds more professional. Dedicated databases are not inherently better engineering, they are a specific trade with specific costs.
ProTrader gives each white-label tenant its own dedicated database and its own domain, provisioned automatically by a control plane with no manual setup step. The data is trading performance tied to real broker accounts, which justified the cost of hard isolation.
AgencyOS went the other way, running one API across a 78-model domain serving operator, admin and client portals. Same platform shape, different answer, because the sensitivity profile and the tenant economics were different.
For most products, yes. It moves the tenant filter from application code that can forget it into the database that cannot, which eliminates the most common leak. It does not give the structural separation that regulated or highly sensitive data sometimes requires.
As a resumable job rather than a deploy step. Track which tenants are on which version, apply in batches, and make every migration safe to re-run, because a failure partway through leaves the fleet in a mixed-version state you have to be able to recover from.
A shared database with a tenant column, by a wide margin. One schema, one migration, one connection pool, and cost that scales with total usage rather than tenant count. The saving is real, and so is the risk it accepts.
Yes, and it is worth designing for if you expect enterprise customers. It means keeping tenant data cleanly separable from day one and having an export and import path, which is much easier to build early than to retrofit under contractual pressure.