What is multi-tenancy?

Multi-tenancy is the architecture that lets a single application serve multiple separate organisations — "tenants" — where each organisation's users can only see their own data. An accounting firm using your app shouldn't be able to see another firm's clients. A franchisee shouldn't see another franchisee's orders.

Every B2B SaaS product is, at its core, a multi-tenant application. The users are members of an organisation, and the organisation is the billing unit. Features like role-based access, org-level settings, and usage limits all sit on top of the tenant layer.

The critical decision is tenant isolation strategy: row-level security (all tenants share the same tables, with a tenant_id column on every row and a policy enforcing access) vs schema-per-tenant (each tenant gets their own database schema). Row-level security in PostgreSQL is the most common approach for new applications — it's simpler to manage and scales well for hundreds to thousands of tenants.

When does your app need it?

• You're building a B2B SaaS product where customers are organisations, not individuals
• Multiple users from the same company need access, and they should see each other's work but not other companies' data
• You need to bill per organisation (not per user), set org-level subscription tiers, or apply usage limits at the org level
• Your enterprise customers require that their data is logically isolated from other customers
• You need to support org-level settings — custom branding, feature flags, or configuration that varies between customers
• You're building a marketplace or platform where multiple businesses operate independently within the same product

How much does it cost?

Adding multi-tenant organisations typically adds 11–21 hours of development — roughly $2,000–$5,000 AUD.

At the lower end: a clean greenfield implementation with row-level security in PostgreSQL, a user-to-org membership table, basic roles (owner, admin, member), and an invitation flow. If this is built from the start, it integrates cleanly into the data model.

At the higher end: retrofitting multi-tenancy onto an existing single-tenant app (expensive and risky), schema-per-tenant isolation, per-org billing with Stripe, org-level settings and configuration, custom roles with fine-grained permissions, and member management UI (invite, remove, change role). The invitation flow with email delivery, token expiry, and new vs existing user handling adds meaningful time on its own.

How it's typically built

Row-level security (RLS) in PostgreSQL is the preferred approach. Every table that holds tenant-specific data has a tenant_id (or organisation_id) column. RLS policies are defined at the database level so that queries automatically filter to the current tenant — even if application code forgets to include a filter, the database enforces isolation. The current tenant is set at the start of each request via a session variable.

The membership model is a join table: users ↔ organisation_members ↔ organisations, with a role column on the membership. A user can be a member of multiple organisations (with a current-org switcher in the UI), or restricted to one.

Invitation flows generate a signed, time-limited token. Clicking the email link either creates a new user account and adds them to the org, or (if they already have an account) logs them in and adds the membership. This edge case — existing vs new user — is the trickiest part.

Billing per org means the Stripe customer and subscription are attached to the organisation, not the user. Seat counts, usage limits, and feature flags are checked at the org level.

Questions to ask your developer

• Row-level security or schema-per-tenant? RLS is usually the right call for new apps — ask for the reasoning behind whichever approach is proposed.
• Is tenant_id enforced at the database level or only in application code? Application-level filtering is a single bug away from a data leak. Database-level RLS policies are much safer.
• How are invitations handled for users who don't yet have an account? This edge case needs explicit design — what happens to the invite token after the user signs up?
• Can a user belong to multiple organisations? If so, how is the active org determined, and is there a switcher in the UI?
• How is org-level billing handled? Is the Stripe subscription on the org, and how are seat counts or usage limits enforced?

---

See also: Role-based permissions · Enterprise SSO · Subscription billing · App cost calculator