Multi-Tenancy Is More Than Organizations
“Do you support multi-tenancy?” It’s one of the first questions an enterprise prospect asks. And almost every SaaS platform answers: “Yes, we have Organizations.”
That answer is technically true and practically misleading. An Organizations feature in your auth layer is a starting point for multi-tenancy. It is not multi-tenancy.
What Most Platforms Call Multi-Tenancy
Here’s what you typically get when a platform says they support multi-tenancy:
- Users can be grouped into an Organization
- Admins can manage membership
- Maybe: per-org SSO configuration
- Maybe: per-org role assignments
That’s it. Your auth system knows about organizations. Everything else in your stack does not.
Your feature flags? They evaluate against a user or an environment — not an organization. You can’t roll out a feature to a specific tenant. You can’t give one customer beta access while another stays on stable. You’re back to hardcoding customer IDs in your flag logic.
Your billing? It’s attached to a Stripe customer — usually the account owner who signed up. If you have 200 users across 40 organizations, your billing system doesn’t know which organization generated which revenue. Churn analysis by tier is a spreadsheet exercise.
Your rate limiter? It’s probably keyed on API key or IP. Not on organization. A single power user in a free-tier org can consume quota that should be shared across their whole team.
Your audit logs? If you have them, they’re probably a database table with a user_id column. You can query what a user did. You cannot easily query what a tenant did — because your logs don’t carry org context.
What Real Multi-Tenancy Requires
True multi-tenancy means tenant context flows through every layer of your infrastructure:
- Per-tenant feature flags — roll out features to specific organizations, not just user cohorts
- Per-tenant billing — usage, limits, and charges are scoped to the organization, not the individual
- Per-tenant rate limits — a tenant’s quota is shared across all their users, enforced at the org level
- Per-tenant audit logs — every action carries org context, and you can query the full history of what any tenant has done
- Per-tenant config — feature toggles, webhook endpoints, notification preferences — all scoped to the org
- Per-tenant data isolation — row-level security, namespace isolation, or logical separation that prevents data leakage across tenants
None of this is exotic. It’s table stakes for B2B SaaS. But it requires intentional architecture — not an afterthought Organizations checkbox.
Flux’s Approach
In Flux, the tenant context is a first-class concept that flows through everything. When you make a flag evaluation, the organization is part of the evaluation context — not an optional field you remember to pass. When you record a billing event, it’s scoped to the organization. When you check a rate limit, it’s enforced at the org level by default.
This means:
- Flag targeting rules can reference
org.plan,org.id,org.created_at, or any custom attribute you set on the organization - Billing metrics are aggregated per-org, so you always know what a tenant is consuming
- Rate limits are configured per-org, with the ability to override limits for specific high-value customers
- Every Flux operation emits an audit event with full org context — no manual tagging required
The Test
Here’s a simple test for whether you actually have multi-tenancy: Can you answer “show me everything tenant X has done in the last 30 days” with a single query?
Not “here’s what user A did.” Not “here are all events that happened to mention company X.” The full picture — flags evaluated, billing events processed, config changes made, auth events, rate limit hits, errors — all scoped to a single tenant, in one place.
If the answer is no, you have an Organizations feature. You don’t have multi-tenancy.
Enjoyed this post? Get updates from the Flux blog.