Table of Contents
Introduction
Building a white-label data portal that serves multiple clients from a shared infrastructure requires getting a specific set of architectural decisions right at the start. The decisions that seem like implementation details — how tenant data is stored, how access controls are enforced, how new tenants are onboarded — turn out to be the decisions that determine whether the platform scales to hundreds of tenants or breaks under the weight of the tenth one.
This post covers the core architectural patterns for multi-tenant data portals built on Power BI Embedded and Azure, with specific attention to the trade-offs that ISVs and SaaS platform teams face when designing for tenant isolation, scalability, and cost predictability.
Data Isolation: Three Patterns and Their Trade-Offs
The starting point for multi-tenant portal architecture is the data isolation model. Three patterns exist, each with different implications for security, cost, and operational complexity.
Pattern 1: Shared database with TenantID and RLS. All tenants’ data lives in the same database tables, differentiated by a TenantID column. Row-Level Security at the database layer (or in Power BI) filters each tenant’s queries to their own rows. This is the most storage-efficient pattern and the easiest to manage at small tenant counts. The risk: if RLS is misconfigured, a tenant can see another tenant’s data. In regulated industries or with large enterprise tenants, this risk may be unacceptable.
Pattern 2: Separate databases per tenant. Each tenant has a dedicated database schema or database instance. This provides complete isolation — a misconfigured query cannot cross tenant boundaries because the data is physically separated. The cost is operational complexity: managing connections, running aggregate queries across tenants, and deploying schema changes to 100 or 1,000 tenant databases requires automation and tooling that must be built and maintained.
Pattern 3: Hybrid approach. Small tenants on shared databases with RLS; large or regulated tenants on dedicated databases. This balances cost efficiency at the low end with isolation requirements at the high end, but it creates architectural divergence that must be managed explicitly.
For most ISVs starting out, Pattern 1 with rigorously tested RLS is the right starting point. The move to tenant-isolated databases (Pattern 2) is justified when tenant-specific compliance requirements, data volumes, or contractual commitments make shared-database risk unacceptable.
Power BI Embedded: App Owns Data and RLS Implementation
The standard embedding pattern for white-label data portals is “App Owns Data.” In this model, the portal application authenticates to Power BI using a service principal (not individual user accounts). The portal generates embed tokens for each user session, and RLS filtering is applied through the embed token — specifying the tenant identifier or user role that the token represents.
This means your portal users never need Power BI licenses. They interact with embedded reports through your application’s authentication. The service principal owns the Power BI workspace and manages the dataset and report permissions centrally.
The RLS implementation in this model works as follows: a single Power BI report connects to a single dataset (or Fabric Semantic Model). The dataset includes a Permissions table linking user identities to tenant identifiers or data access scopes. When the portal generates an embed token for a user, it passes the user’s identity or role to Power BI, which applies the RLS filter at query time — ensuring that user sees only their tenant’s data.
For tenant onboarding automation at scale, Microsoft recommends executing a standard series of REST API calls via service principal: create a new workspace, associate it with a dedicated capacity, import a Power BI Desktop file, and set the semantic model source credentials. This sequence can be automated with PowerShell or the Power BI REST API, making per-tenant provisioning scalable beyond the point where manual provisioning becomes impractical (roughly 10+ tenants).
Capacity Planning: F64 and Tenant Density
A Microsoft Fabric F64 capacity (or equivalent Power BI Premium P1 capacity) can support approximately 50–100 small tenants sharing the capacity. Large tenants with high report complexity or frequent concurrent users may require dedicated capacity allocation.
Capacity smoothing in Fabric means transient spikes in a single tenant’s usage are absorbed by borrowing from future capacity headroom, preventing throttling during temporary peaks. Sustained over-utilization across tenants — where aggregate demand consistently exceeds the capacity SKU — causes throttling that affects all tenants on that capacity.
The capacity planning approach for multi-tenant portals is: establish a baseline report complexity and concurrent user count per tenant tier (small, medium, large), model aggregate demand against capacity at the expected tenant count for each tier, and size capacity SKUs accordingly. Monitor per-tenant usage through Fabric’s capacity metrics to identify tenants approaching limits and proactively move large consumers to dedicated capacity before they affect shared-capacity neighbors.
Report Customization and Schema Evolution: The Hard Problems
Two operational challenges consistently emerge in multi-tenant portals at scale.
Report customization. Enterprise tenants frequently want branded reports — their logo, their color scheme, their field naming conventions. Delivering tenant-specific branding while maintaining a single report template requires parameterization (using Power BI’s dynamic title and conditional formatting features with parameters passed through embed tokens) or per-tenant report copies (which creates a maintenance burden when the report template changes).
Schema evolution. When the underlying data schema changes — new columns, renamed tables, modified relationships — that change must be deployed across all tenant databases in Pattern 2 architectures. Without automation, deploying a schema change to 200 tenant databases is a manual, error-prone exercise. Infrastructure-as-code tooling (Azure DevOps pipelines, Terraform, or Bicep) applied to tenant database provisioning and schema management is the operational foundation that makes schema evolution tractable at scale.
Prism Analytics teams building white-label data portals have found that the gap between “working for 5 tenants” and “working for 100 tenants” is almost entirely an automation and governance problem — the report design and data model are secondary concerns compared to the operational machinery needed to provision, update, and monitor at scale.
Conclusion
Multi-tenant data portal architecture is a solved problem at the pattern level — the data isolation options, embedding patterns, and capacity models are well-documented. The execution challenge is in the operational automation that makes those patterns scale: tenant onboarding pipelines, schema deployment tooling, capacity monitoring, and per-tenant customization frameworks. Building those foundations early prevents the architectural debt that accumulates when the first 10 tenants are provisioned manually.
Prism Analytics partners with enterprises across the Microsoft data ecosystem — from white-label data portals to Microsoft Fabric development and Power BI embedded analytics. Contact us to explore how we can help.