A technical guide to multi-tenant embedded analytics — architecture patterns, security models, common pitfalls, and what engineering teams consistently underestimate when building for SaaS scale.
TL;DR Multi-tenant analytics means delivering dashboards from a single application instance to many customer organisations, each seeing only their own data, possibly with their own branding. The three main architectural patterns are shared database with Row-Level Security (most common), database-per-tenant (highest isolation, hardest to operate), and hybrid models. Getting multi-tenancy right is harder than most teams expect — Row-Level Security misconfigurations have caused data breaches at high-profile SaaS companies. Platforms like Power BI Embedded with DataTako handle the multi-tenant work; custom builds require careful security testing and ongoing audit.
Why multi-tenancy is harder than it looks
Multi-tenant analytics seems simple on paper. Each customer signs in, sees their own data, has their own dashboards. The architecture diagram fits on a napkin.
In practice, multi-tenancy is where embedded analytics projects most often fail in expensive, public ways. Row-Level Security misconfigurations at major SaaS companies have exposed customer data in incidents that made tech news headlines. The patterns that fail are predictable; the teams that fail to anticipate them are predictable too.
The reason is that multi-tenancy intersects every part of the stack: data modelling, authentication, authorisation, query execution, caching, branding, audit logging, and operations. A subtle issue in any of these layers can leak one tenant's data to another. The compound surface area is large; the testing required to validate it all is non-trivial.
This guide covers the architectural patterns that work, the security models that hold up under audit, and the operational realities engineering leads underestimate. If you're choosing between building multi-tenant analytics yourself or using a platform that handles it, the second half of this guide makes that comparison concrete.
For the broader context, see our embedded analytics overview.
The three multi-tenancy architecture patterns
Every multi-tenant analytics architecture is one of three patterns or a hybrid.
Pattern 1: Shared database with Row-Level Security
The dominant pattern for SaaS. All customer data lives in the same database tables, with a tenant identifier column (typically tenant_id or organization_id) that scopes which rows belong to which customer. Row-Level Security rules enforce that queries only return data for the authenticated tenant.
How it works. A query against the orders table is automatically filtered to WHERE tenant_id = current_user_tenant(). The filter is applied transparently — the application code looks like it's querying a single-tenant database, but the database (or BI layer) enforces tenant isolation.
Strengths. Operationally simple — one database to back up, one schema to migrate, one set of indexes to maintain. Cost-efficient because resources are shared across all tenants. Easier to query across tenants for product-team analytics (subject to access controls).
Weaknesses. Single point of failure for security. A bug in the RLS configuration affects every tenant simultaneously. Performance can degrade as table sizes grow — large tenants and small tenants compete for the same indexes. Compliance-sensitive industries sometimes require stronger isolation than this pattern provides.
When to use. Default choice for most SaaS embedded analytics. Works well from a few tenants up to thousands. The most common pattern in Power BI Embedded, Tableau Embedded, and dedicated platforms like Sisense.
See Row-Level Security implementation in Power BI for the implementation details on this pattern.
Pattern 2: Database-per-tenant
Each tenant gets their own database (or schema, or workspace). Complete isolation at the storage layer — there's no shared table with a tenant filter, because there's no shared table.
How it works. A new tenant triggers provisioning of a new database. The application's connection pool routes queries to the appropriate database based on the authenticated tenant. Schema changes have to be deployed to every database separately.
Strengths. Strongest isolation. A bug in tenant routing can't accidentally show tenant A's data to tenant B because the data isn't in the same place. Easier to support per-tenant customisations (schema variations, custom calculated columns). Tenant-specific performance tuning is possible.
Weaknesses. Operationally expensive. Schema migrations have to be deployed to every tenant. Backups and monitoring multiply. Provisioning new tenants is more complex. Costs scale with tenant count rather than aggregate usage.
When to use. Highly regulated industries (healthcare with HIPAA, financial services with specific compliance requirements), tenants that genuinely require physical isolation, or platforms with very few but very large tenants where the operational overhead is amortised.
Pattern 3: Hybrid (shared with bridging)
Most SaaS at scale ends up here. Some data is shared (product configuration, lookup tables) and some is tenant-specific. Tenant isolation uses RLS for shared tables and per-tenant separation for tenant-specific tables.
How it works. Schema design distinguishes "tenant-owned data" (orders, customers, transactions) from "global data" (product catalog, country codes, default configurations). RLS protects tenant data; global data is accessible without filtering.
Strengths. Captures most of the operational efficiency of shared databases with cleaner mental separation between tenant and global data. Common ground between development teams and security teams.
Weaknesses. More complex than either pure pattern. Requires careful schema design and ongoing discipline to keep the boundary clean. Sometimes ends up being shared-with-RLS in practice with the "hybrid" label for marketing reasons.
When to use. When you have legitimate global data that doesn't need tenant scoping. Most B2B SaaS products develop this pattern naturally as the product matures.
How Row-Level Security actually works in embedded analytics
Row-Level Security is the security primitive that makes shared-database multi-tenancy safe. Done well, it's invisible and rock-solid. Done badly, it's the source of the major data breaches.
The key concept: RLS rules apply at query time, automatically, regardless of what the application code intends. A query like SELECT * FROM orders doesn't return all orders — it returns only orders the current user should see, because the RLS rule appends a tenant filter to every query.
In embedded analytics specifically, RLS works through one of two mechanisms:
Database-level RLS is enforced by the database itself (PostgreSQL RLS, SQL Server RLS, etc.). Every query against the database has the rules applied. This is the strongest enforcement model because no application bug can bypass it.
BI-layer RLS is enforced by the embedded analytics platform. The platform receives queries from the embedded dashboards, applies tenant-scoping rules based on the authenticated user identity, and only returns scoped results. Power BI Embedded works this way with DAX-based RLS rules.
The two can be combined — RLS at the database layer plus RLS at the BI layer. Belt-and-braces but operationally heavier.
The identity that drives RLS varies by platform. In Power BI Embedded with app-owns-data, the identity comes through the embed token's effectiveIdentity parameter. The application generates a token with the current customer's identity, and Power BI's DAX RLS rules read that identity via USERNAME(), USERPRINCIPALNAME(), or CUSTOMDATA() to filter the data.
In Tableau Embedded, identity passes through the embed parameters and is consumed by user filters or row-level security rules at the workbook level.
In Sisense, identity comes through the JavaScript SDK and is consumed by data security definitions at the model level.
In all cases, the key principle is: identity flows from your application's authentication into the BI layer's filtering logic, transparently for each query. If that identity flow breaks anywhere, tenant isolation breaks.
The common pitfalls that cause multi-tenant breaches
The data breaches we read about in tech news rarely happen because someone forgot to set up RLS. They happen because RLS was set up but configured incorrectly in a way that wasn't tested thoroughly enough. Patterns:
The default-allow trap. Some platforms default to "show all data unless a rule restricts it." If a tenant is created without RLS configuration, or with a rule that fails to match, the default behaviour is to show everything. Better platforms default-deny (no data shown unless a matching rule grants access).
The missing-user-on-token bug. When the application generates an embed token, it has to include the user's identity. If a code path generates a token without identity (perhaps a "service" or "anonymous" pathway used internally), and that path becomes accessible to end users, RLS fails open. This has been the cause of several public incidents.
The shared-user pattern. Some products use shared user accounts for guest access or marketing demos. If those shared accounts get assigned to multiple tenants (often by mistake during onboarding), RLS rules that filter by user identity start returning data from multiple tenants.
The schema-change blind spot. Schema changes (adding new tables, new columns) sometimes get deployed without corresponding RLS rules. The new data isn't protected by any rule and is visible across tenants. Catching this requires deployment processes that audit RLS coverage on every schema change.
The role-inheritance issue. Admin users sometimes have rules that bypass tenant filtering for support purposes. If end users inherit admin roles by mistake (a common error in identity management), they bypass tenant filtering too. Audit role hierarchies regularly.
The cache poisoning risk. Caching dashboards for performance is common; caching them incorrectly per-tenant has caused tenant A to see cached results from tenant B. Cache keys must include tenant identity, always, without exception.
The cross-tenant report sharing pitfall. When users share dashboard links, the links sometimes work for users in other tenants if the URL doesn't carry tenant context. Test cross-tenant link access explicitly.
The export pathway gap. A user might be restricted in the UI but able to export raw data via an API that doesn't apply the same RLS rules. Audit every data access pathway, not just the primary UI.
Every one of these has caused a real data breach at a real SaaS company. The pattern is always the same: RLS was configured for the primary path, and an edge case bypassed it.
What testing multi-tenancy actually requires
Validating multi-tenant isolation is harder than functional testing because the test cases aren't "does it work?" but "does it fail safely under edge conditions?". The testing matrix has to cover:
Cross-tenant query attempts. Generate tokens for tenant A users and explicitly try to query tenant B data. Expected result: no data returned. Run this test for every query type your platform supports.
Missing-tenant token tests. Generate tokens without tenant identity (or with malformed identity). Expected result: zero data returned, ideally an explicit error rather than a silent empty result.
Role hierarchy tests. Verify that role hierarchies (admin, manager, viewer) don't inadvertently grant cross-tenant access. Map out which roles can see which data and test each combination.
Cache validation. Generate dashboards for tenant A, immediately query as tenant B, verify cache returns tenant B's data (not tenant A's cached result). Test cache invalidation patterns specifically.
Schema change auditing. Every database schema migration must trigger an audit: are all new tables and columns protected by RLS? Build this into deployment pipelines, not retrospective audits.
Penetration testing. External security audits specifically for multi-tenancy. The third-party tests find issues internal tests miss.
Production monitoring for anomalies. Tenant A's user querying tenant B's data should never succeed — but if it ever does, you need alerts that fire immediately, not weeks later in audit logs.
Compliance documentation. Regulated industries require documented evidence of multi-tenant isolation. Build the documentation as you build the system; reconstructing it later is painful.
This testing matrix is non-trivial. Teams building multi-tenant analytics themselves underestimate it consistently — typical projects budget for functional testing but not for tenant-isolation testing at this depth.
How platforms differ on multi-tenancy
Different embedded analytics platforms handle multi-tenancy differently, and the differences matter.
Power BI Embedded is strong on multi-tenancy when used in the app-owns-data pattern. Embed tokens carry effective identity, DAX RLS rules filter by identity, and the architecture is designed for SaaS-scale multi-tenancy. The complexity is in implementation — getting the embed token plumbing right is engineering work, and the audit trail relies on Microsoft's audit logs which are tenant-level rather than viewer-level. DataTako adds per-viewer audit logging and operational tooling on top.
Tableau Embedded supports multi-tenancy through user filters and row-level security, but the patterns are less SaaS-native. Tableau was designed for internal BI and retrofitted for embedding; multi-tenant implementations require workspace or project-level segmentation that doesn't scale as smoothly as Power BI's identity-token approach.
Looker Embedded uses LookML-defined access grants tied to user attributes. The model is powerful for engineering-led teams comfortable with code-first configuration. Less straightforward for teams expecting UI-based multi-tenant configuration.
Sisense has multi-tenancy primitives built in. Data security definitions at the model level, plus user attributes that drive filtering. Strong choice for SaaS specifically.
Qrvey is purpose-built for multi-tenant SaaS, with tenant isolation as a first-class concern from the architecture up. AWS-native deployment lets you put tenants in separate accounts or VPCs for additional isolation.
Cube and Embeddable delegate multi-tenancy to your application code — they provide the semantic layer, but tenant scoping is your responsibility. Maximum flexibility, maximum responsibility.
Metabase supports multi-tenancy primarily through database-level RLS or careful collection/dashboard organisation. Less mature than dedicated SaaS platforms for true multi-tenant scenarios.
For Power BI specifically, see our Power BI Embedded guide and Row-Level Security implementation.
The operational dimensions teams underestimate
Beyond the security and architecture, multi-tenancy creates operational complexity that's easy to underestimate:
Onboarding new tenants. Each new tenant needs provisioning — schema setup, RLS rules, branding configuration, user invites, initial data load. At scale, this becomes a workflow that needs automation, not a checklist.
Tenant-specific support. Customer support requires the ability to view a tenant's experience without seeing their actual customer data. The patterns for this (impersonation with audit logs, read-only access modes, sandbox environments) need to be designed up front.
Performance isolation. Without explicit isolation, one heavy tenant can degrade performance for all others. Capacity-based platforms (Power BI Embedded) handle this differently from per-tenant database patterns; understand the model before scaling.
Tenant deletion and offboarding. When a customer churns, their data needs to be removed cleanly — for compliance (GDPR right-to-deletion) and for cost management. The processes are easier to design at the start than to retrofit later.
Multi-tenant analytics on the analytics. You'll want to know which tenants use which dashboards most. This requires logging at the tenant level, which has its own privacy and compliance considerations.
Cross-tenant aggregations for internal use. Product teams want aggregate insights across all tenants ("how many of our customers use feature X?"). The infrastructure to safely aggregate across tenants without leaking individual tenant data is its own engineering problem.
Tenant configuration drift. Over time, different tenants accumulate different configurations — feature flags, theme settings, custom calculations. Managing this configuration sprawl is an ongoing operational tax.
These dimensions typically add 30-50% to multi-tenant projects beyond the architectural and security work. Teams that scope only the security work and underestimate operations end up overrunning.
Where DataTako fits the multi-tenant analytics problem
DataTako exists specifically to handle multi-tenancy on Power BI Embedded without requiring engineering teams to build it themselves.
What DataTako provides:
Tenant scoping via Row-Level Security. RLS rules wired to your customer identities, with the embed token plumbing handled automatically. You provide the customer-to-tenant mapping; DataTako handles the rest.
Per-tenant user management. Each tenant has its own users, groups, and access controls. Adding a new user to tenant A is two clicks; no risk of accidentally adding them to tenant B.
Per-tenant branding. Each tenant can have its own logo, colours, and visual identity. The branding configuration is isolated per tenant, with no cross-tenant leakage.
Per-viewer audit logs. Every dashboard view logged with user, tenant, timestamp, IP, and content accessed. The granularity compliance teams want, automatically generated.
Cache scoping by tenant. Caching is automatic and tenant-aware — no engineering work needed to prevent cross-tenant cache poisoning.
Tenant provisioning automation. Creating new tenants is automated. No manual schema work, no RLS rule configuration, no onboarding checklist drift.
Support impersonation with audit. Support staff can impersonate users for troubleshooting; every impersonation is logged. The patterns for safe support access are built in.
For SaaS teams choosing Power BI Embedded for multi-tenant analytics, the realistic choice is: build all of the above yourself (4-6 months of engineering, plus ongoing security maintenance) or use DataTako (configuration, not engineering). For most teams, DataTako is the answer that lets engineers focus on workflow features instead of multi-tenancy infrastructure.
For agency-specific patterns, see the BI agency playbook. For SaaS-specific patterns, see embedded analytics for SaaS: a complete buyer's guide.
Frequently asked questions
What is multi-tenant analytics? Multi-tenant analytics means a single application instance serves multiple customer organisations, each seeing only their own data. Each tenant has isolated access to their dashboards, often with their own branding. The standard architecture for SaaS embedded analytics.
What's the difference between multi-tenant and single-tenant analytics? Single-tenant means a dedicated deployment per customer — separate instance, separate database, separate everything. Multi-tenant shares infrastructure across customers with logical isolation. Single-tenant is operationally expensive but simpler to secure; multi-tenant is operationally efficient but security-critical.
Is Row-Level Security enough for multi-tenancy? RLS is the primary security mechanism, but not the only requirement. Multi-tenant analytics also needs identity flow validation, cache scoping, role hierarchy auditing, export pathway protection, and schema change audit. RLS alone doesn't catch all the edge cases.
Which platforms handle multi-tenancy best? Power BI Embedded with app-owns-data pattern, Sisense (purpose-built for multi-tenant SaaS), Qrvey (multi-tenant focus), and Cube (delegated to your application code) all handle multi-tenancy well. Tableau Embedded and Looker support it but with more retrofitting.
Can I add multi-tenancy to an existing single-tenant analytics product? Yes, but it's a substantial migration. The data model needs tenant identifiers, all queries need tenant scoping, authentication needs to carry tenant identity, and the operational tooling has to change. Plan for several months of engineering work.
What's the biggest mistake teams make with multi-tenant analytics? Underestimating the testing required. RLS configurations look correct until an edge case proves otherwise. Comprehensive multi-tenant testing — cross-tenant query attempts, role hierarchy validation, cache scoping verification — is non-trivial and often skipped, with predictable consequences.
Does multi-tenancy affect performance? It can. Shared databases mean tenants share resources; heavy tenants can degrade performance for light tenants. Capacity-based platforms (Power BI Embedded F SKUs) help by providing predictable capacity per workload. Database-per-tenant patterns provide hard isolation but at operational cost.
How do I test multi-tenant isolation properly? Generate tokens for tenant A, attempt to query tenant B data, verify zero results. Test for every query type and every API. Test missing-tenant tokens, role hierarchies, cache invalidation, and schema migration coverage. External penetration testing for additional assurance.
Should I use database-per-tenant or shared database with RLS? Default to shared database with RLS for most SaaS. Database-per-tenant only if you have specific isolation requirements (regulated industries, very few large tenants) or compliance requirements that mandate physical isolation. The operational cost of database-per-tenant is significant.
How does DataTako handle multi-tenancy? DataTako sits on top of Power BI Embedded and provides tenant scoping, per-tenant branding, audit logging, and operational tooling for multi-tenant SaaS. Engineering teams don't have to build the multi-tenant infrastructure themselves — DataTako provides it as configuration.
