Multi-tenancy is an ownership model
The first mistake in multi-tenant SaaS is treating tenancy as a database column. The real problem is deciding who owns each resource, which organization context applies and how access is enforced at every boundary.
1. Model organizations and memberships
A user may belong to one or many organizations. Membership carries role, status and potentially organization-specific configuration. Resources should reference the tenant boundary explicitly.
2. Choose isolation deliberately
Common models include a shared database with tenant-scoped records, schema/database isolation for stronger boundaries, and hybrid designs for selected high-value tenants. The decision should follow risk, scale, operations and data residency requirements.
3. Authorization must be tenant-aware
Every protected action should answer both questions: may this actor perform the action, and does the target resource belong to the active organization context?
4. Add defense in depth where risk justifies it
Application authorization remains the domain gate. Database-level controls such as PostgreSQL Row-Level Security can add another boundary for selected architectures, but they do not replace a coherent product authorization model.
5. Tenant context affects more than data
Billing, entitlements, feature flags, notification preferences, branding, integrations, audit logs and support workflows often depend on the organization context.
Operational questions to answer before launch
- How are organizations created and deleted?
- How do invitations and ownership transfer work?
- What happens when a user changes organization?
- How are background jobs scoped to a tenant?
- How can support inspect a tenant without bypassing audit?