On a shared multi-tenant Apache Superset instance, ensuring data isolation between customers is critical. Bad isolation = data leak = lawsuit. This guide details isolation patterns for 2026.
1. Isolation levels
| Level | Cost | Security |
|---|---|---|
| Logical (RLS) | Low | Medium (depends on RLS) |
| Schema-level | Medium | Good |
| Database-level | High | Strong |
| Instance-level | Very high | Maximum |
If you want strong per-customer isolation, TVL Managed Superset offers a "dedicated instance per tenant" mode on Pro+.
2. Pattern 1 — Dynamic RLS
All tenants share the same database, isolation via Row Level Security:
-- Superset dataset configured with RLS
SELECT *
FROM orders
WHERE tenant_id = '{{ current_user_tenant() }}'
See detailed RLS guide.
3. Pattern 2 — Separate schemas
Each tenant has its Postgres schema:
CREATE SCHEMA tenant_acme;
CREATE SCHEMA tenant_globex;
GRANT USAGE ON SCHEMA tenant_acme TO superset_acme_role;
On Superset side, create a dataset per schema with role → schema mapping. Safer than pure RLS, but requires one dataset per tenant.
4. Pattern 3 — Separate databases
One database per tenant. Very safe but expensive in infra. Ideal for regulated sectors (banking, health).
5. Pattern 4 — Superset instance per tenant
Each tenant has its own complete Superset instance. Total isolation, but cost × N tenants. See complete multi-tenant.
6. Coupling with embedded
For multi-tenant embedded SaaS:
- Pattern 1 (RLS) with signed guest token that injects the tenant_id;
- The RLS filter triggers automatically;
- See embedded dashboards.
This configuration is applied by default on TVL Managed Superset, which follows community best practices.
7. Isolation tests
To automate in CI:
# Test: tenant A user must not see tenant B data
def test_isolation():
token_a = get_guest_token(tenant_id="A")
response = call_dashboard_api(token_a, dashboard_id=42)
data = response.json()
assert all(row["tenant_id"] == "A" for row in data["rows"])
8. Per-tenant audit log
The audit trail must identify the tenant for each action:
- Log the tenant_id on each SQL Lab query;
- Log dashboard access with tenant;
- Be able to extract audit for a given tenant (GDPR DSAR).
9. Common pitfalls
- RLS bypassed by SQL Lab if user has direct access;
- Unintentional cross-tenant join in a virtual dataset;
- Shared cache between tenants without prefix → cross-tenant cache hit;
- Global dashboards badly scoped expose all tenants;
- No automated tests → silent regression possible.
10. Conclusion
Multi-tenant isolation is one of the most critical aspects of a SaaS Superset architecture. For sensitive data, don't settle for pure RLS: combine with audit, CI tests, and prefer separate schemas/databases. For highly regulated sectors, instance per tenant remains the standard.
Want the benefits of Apache Superset without the friction of installation and maintenance? Deploy your instance in 3 clicks with TVL Managed Superset, hosted in Europe (OVHcloud, Roubaix, France).
For more: multi-tenant architecture, RLS, embedded.