Multi-tenancy is the architecture decision that quietly governs your SaaS for the rest of its life. Get it right and it's invisible. Get it wrong and every feature you ship for the next five years has a "make sure to filter by tenant" footnote that someone, eventually, will forget.
Here's what I've learned from scoping SaaS builds for Australian founders.
The three architectures
- Shared database, shared schema, tenant_id everywhere. Most common. Easy to start, hard to enforce. Every query needs `WHERE tenant_id = ?` and any forgotten one is a data leak.
- Shared database, schema-per-tenant. Each tenant gets its own Postgres schema. Cleaner isolation. Harder to operate at scale (1000+ tenants gets ugly).
- Database-per-tenant. Strongest isolation. Used by enterprise SaaS where customers want data residency or independence. Operationally painful below 50 tenants.
Most Australian SaaS startups should pick option one. Most should also enforce isolation at the database layer with row-level security, not in application code.
Row-level security: the underused superpower
Postgres has built-in RLS. You define a policy ("tenants only see their own rows"), set a session variable on each connection (`SET app.tenant_id = '...'`), and Postgres enforces the filter on every query.
Why this matters: even if a developer writes a SQL query that forgets the tenant filter, Postgres adds it for them. The data leak isn't possible.
Most JavaScript ORMs (Prisma, Drizzle, etc.) don't enable RLS by default. It's a 1-day setup. Worth every minute.
Multi-tenancy enforced in code is a checklist. Multi-tenancy enforced in the database is a guarantee. Always pick the guarantee.
The decisions that bite later
- User-tenant relationships. Can one user belong to multiple tenants? If yes, build it now, retrofitting it after launch is painful.
- Tenant-level vs user-level settings. Some settings belong to the org, some to the user. Decide the model upfront.
- Cross-tenant features. Will tenants ever share data, invite each other, or interact? If yes, that's a different architecture from "isolated silos."
- Data export. Tenants will eventually want to leave with their data. Build this from day one, it's also useful for backup and migration.
- Tenant deletion. Soft delete vs hard delete. Australian privacy law has opinions; check before designing.
Auth and tenants
Three patterns:
- One login per tenant. Customers create an account scoped to one organisation. Simplest; works for most B2B SaaS.
- Single login, multiple tenants. Like Slack. Same email/account, choose which workspace at login. More complex but better UX for power users.
- SSO with tenant detection. Enterprise customers log in via their IdP, get routed to their tenant. Required for serious enterprise sales.
Pick one and stick with it. Switching after launch is a multi-week project.
Billing and tenants
The tenant is usually the billing entity, not the user. So:
- Stripe Customer = your tenant (organisation), not your user.
- Stripe Subscription belongs to the tenant.
- Per-seat pricing means tracking tenant.user_count and updating Stripe quantity.
This sounds obvious but I see it modeled wrong about half the time. Modeling user→subscription instead of tenant→subscription kills your billing as soon as multi-user accounts arrive.
Admin and impersonation
Build internal admin from day one with two features:
- Tenant lookup. Search by tenant name/email, see their data, see their billing.
- Customer impersonation. Log in as a customer to debug. Audit-logged. Time-limited. Gold for support; absolutely a security risk if not done carefully.
Audit logs
Log who did what, when, from where, on every business-significant action. Two reasons:
- Customers ask for it eventually (usually a quarter before SOC 2 starts).
- You need it for debugging, "who changed this config?" comes up monthly.
Building audit logs from day one is hours of work. Adding them retroactively is weeks.
The "noisy neighbour" problem
Shared infrastructure means one tenant's load can degrade everyone's experience. Solutions:
- Per-tenant rate limits.
- Heavy operations queued, not synchronous.
- Caching that's not bypassed by clever URL params.
- Monitoring that breaks down by tenant, not just total traffic.
The bottom line
Multi-tenancy compounds for years. Use Postgres RLS. Decide your auth model early. Build admin and audit from day one. Don't ship without these, retrofitting them is much, much more expensive than building them right the first time.
If you want three Australian SaaS developers who've shipped multi-tenant before, FindDevs gets you those quotes. Free, three real numbers, in 24 hours.