Power BI Embedded vs Fabric Embedded 2026: ISV + Internal Embedded Analytics Decision Framework

TL;DR

• Power BI Embedded (PBIE) and Fabric Embedded are different products for different scenarios. PBIE is the long-standing Azure-billed product for ISVs and internal embedded analytics; Fabric Embedded is the newer Fabric-capacity offering with deeper Fabric feature parity.
• For ISV scenarios (embedding analytics into a SaaS product sold to external customers), the choice depends on Copilot requirements, Fabric feature dependencies, and the ISV's billing relationship with end customers.
• For internal embedded analytics (embedding Power BI into an internal application like an HR portal or operations dashboard), Fabric Embedded with the right F-SKU is typically the cleaner choice.
• Multi-tenancy patterns differ between the two. PBIE has a long-established service-principal-with-application-owns-data pattern. Fabric Embedded supports the same pattern plus newer patterns leveraging OneLake shortcuts and Workspace-level tenant isolation.
• Pricing is fundamentally different. PBIE A-SKUs are Azure-billed hourly with pause/resume capability. Fabric Embedded uses F-SKU capacity-units billing. Both can be cheaper than the other depending on workload profile.
• This guide is for engineering and product leaders deciding between PBIE and Fabric Embedded for ISV or enterprise embedded-analytics scenarios.

Executive Summary

Embedded analytics is a category Microsoft has supported since Power BI Embedded launched in 2017. The product has been the backbone for hundreds of ISVs embedding Power BI dashboards into their commercial SaaS applications, and for thousands of enterprises embedding Power BI into internal portals. With the maturation of Microsoft Fabric, a second option has emerged: Fabric Embedded, which uses F-SKU capacity and provides access to the broader Fabric feature set.

Both products solve the same core problem — render Power BI content inside a host application with the host controlling authentication, layout, and user experience — but the products are not interchangeable. The decision between them affects pricing model, available features, multi-tenancy patterns, Copilot integration, and the operational model for capacity management.

This guide walks through the decision framework EPC Group has used with ISVs and Fortune 500 enterprises across hundreds of embedded-analytics implementations. We cover the architecture decisions, the multi-tenancy patterns, the capacity-sizing approaches, and the security model.

Why This Decision Matters Now

Three factors converge in 2026 to make this decision urgent:

1. Copilot embedded in customer-facing apps. ISVs and enterprises increasingly want Copilot capabilities inside their embedded analytics surface. Copilot requires Fabric F-SKU capacity. PBIE A-SKUs cannot directly host Copilot.

2. OneLake-backed semantic models in embedded contexts. As enterprises move to DirectLake on OneLake architectures, the question of how that architecture appears in an embedded surface becomes architecturally significant.

3. Pricing model maturity. Both PBIE and Fabric Embedded have refined their pricing in 2025–2026. The cost crossovers between the two have shifted, and organizations that chose one years ago should periodically validate the choice still fits.

The Two Products

Power BI Embedded (PBIE) — Azure A-SKU

PBIE is the Azure-billed embedded-analytics service. Key characteristics:

• Capacity: A1 through A6 SKUs. A1 is the smallest production SKU; A6 is roughly equivalent to a P5 Premium capacity in compute. All A-SKUs are pure compute — they don't include the Premium feature set.
• Billing: Hourly, pay-as-you-go via Azure subscription. Pause and resume capability allows shutting down outside business hours.
• Authentication: Service principal (recommended) or master user. The application owns the data; end users do not need Power BI licenses.
• Multi-tenancy: Service principal with application-owns-data pattern is the established pattern. Each tenant of the ISV's application is typically a workspace in the embedded capacity.
• Features: Standard Power BI feature set. Some Premium features (paginated reports, advanced AI visuals) require Premium-tier A-SKUs (A4+).
• Copilot: Not directly available; would require routing to a Fabric capacity for Copilot calls.

Fabric Embedded — F-SKU

Fabric Embedded uses the same F-SKU capacity model as the rest of Fabric, with embedded as one of the supported workloads. Key characteristics:

• Capacity: F2 through F128+. The smallest production F-SKU for embedded is typically F4 or F8.
• Billing: Capacity-units (CU) billing through the Fabric F-SKU. Pause and resume capability.
• Authentication: Service principal pattern continues to apply. The newer "Embed for your customers" patterns leverage Microsoft Entra External ID for B2C scenarios.
• Multi-tenancy: Workspace-based or domain-based isolation. The May 2026 OneLake domain-level RBAC enhancements enable cleaner multi-tenancy patterns.
• Features: Full Fabric feature set, including Copilot, DirectLake on OneLake, Real-Time Intelligence, Data Activator.
• Copilot: Natively available on F-SKU.

Decision Framework

Decision factor 1: Copilot requirement

If the embedded analytics surface needs to include Copilot capabilities (summarization of report data, natural-language Q&A, AI-generated insights), the answer is Fabric Embedded. PBIE A-SKUs cannot host Copilot directly.

Decision factor 2: Fabric feature dependency

If the underlying semantic model is using Fabric-specific features (DirectLake on OneLake, Real-Time Intelligence streams, OneLake shortcuts), Fabric Embedded is the cleaner architecture. PBIE can consume Fabric-backed semantic models via the Fabric workspace, but the integration is less direct.

Decision factor 3: Pricing profile

Workload profile	Better economic fit
Sporadic usage (off-hours pause every day)	PBIE A-SKU
24×7 production usage	F-SKU (typically cheaper per CU-hour)
Multi-region with regional capacities	F-SKU (more granular SKU choices)
Low base usage with occasional bursts	Either — model both against expected pattern
Heavy AI/Copilot workload	F-SKU (PBIE can't host Copilot)

For workloads with predictable high utilization, F-SKU is typically more cost-effective. For workloads with substantial off-hours, PBIE's hourly billing with aggressive pause/resume can be cheaper. Model both against expected traffic patterns before choosing.

Decision factor 4: Multi-tenancy isolation requirements

For ISVs serving regulated-industry customers (healthcare under HIPAA, financial services under SOC 2), the multi-tenancy isolation requirements may exceed what workspace-level isolation provides. The patterns:

• Workspace per tenant (default). Each customer gets a workspace. Service principal access scoped per workspace.
• Capacity per tenant (high isolation). Each customer gets a dedicated F-SKU or A-SKU. More expensive but provides capacity-level isolation.
• Domain per tenant (Fabric only). OneLake domain-level isolation for tenants that want shared capacity but isolated data domains.

The right pattern depends on the regulatory framework, the contractual commitments to the ISV's customers, and the cost tolerance.

Multi-Tenancy Architecture Patterns

Pattern A: Workspace-per-tenant on PBIE A-SKU

The long-established pattern for ISVs:

1. ISV provisions one Azure subscription with one or more PBIE A-SKUs.
2. Each end-customer of the ISV gets a workspace in the PBIE capacity.
3. ISV's application authenticates via a service principal that has Admin access to all workspaces.
4. ISV's application generates an embed token for the specific workspace + report + user context.
5. End users access the embedded reports through the ISV's application; they never see Power BI directly.

Operational considerations:

• Workspace count is bounded by capacity capability. A1 supports ~50 workspaces comfortably; A6 supports several hundred.
• Refresh schedules need orchestration to avoid concurrent-refresh capacity throttling.
• Capacity-level metrics provide ISV-level visibility but not per-tenant detail (which the ISV typically wants for billing or capacity planning).

Pattern B: Workspace-per-tenant on Fabric F-SKU

The same workspace-per-tenant pattern works on F-SKU with several enhancements:

1. The newer Microsoft Entra External ID integration allows end-user identity federation that PBIE A-SKU does not directly support.
2. OneLake shortcuts let the ISV use a single semantic model surface backed by per-tenant Delta tables, simplifying the model deployment story.
3. Fabric domain governance allows logical grouping of tenant workspaces.

Pattern C: Multi-capacity sharded by tenant

For ISVs with very large customers or strict isolation requirements:

1. Each large customer (or group of customers) is assigned a dedicated F-SKU or PBIE A-SKU.
2. The ISV's application routes embed tokens to the appropriate capacity based on the requesting customer.
3. Capacity-level metrics provide per-customer cost and consumption visibility.

This pattern adds operational overhead but provides per-customer scaling, per-customer SLAs, and per-customer billing transparency.

Pattern D: Domain-isolated on shared capacity (Fabric only)

For Fabric Embedded with OneLake domain-level RBAC:

1. Each tenant is a OneLake domain.
2. Workspaces within the domain are scoped to the tenant.
3. Cross-domain access is explicitly denied.
4. Shared capacity provides cost efficiency; domain-level isolation provides governance.

Security Model

Service principal authentication

Both PBIE and Fabric Embedded support the service principal authentication pattern. The pattern:

1. ISV creates an Azure AD application registration.
2. Service principal is granted appropriate workspace access.
3. ISV's application authenticates as the service principal to obtain an Azure AD token.
4. Azure AD token is exchanged for a Power BI embed token via the Power BI REST API.
5. Embed token is passed to the host application's Power BI Embedded JavaScript SDK to render the report.

Row-Level Security in embedded contexts

RLS continues to apply in embedded contexts. The pattern:

1. RLS rules are defined in the semantic model.
2. Embed token includes the end-user's effective identity (typically the user's email or a synthetic identifier).
3. The Power BI engine evaluates RLS against the end-user identity, not the service principal.
4. End user sees only their authorized rows.

For ISVs where end-user identity is managed in their application's identity store (not in Azure AD), the embed token's identity field is the integration point.

Object-Level Security and Column Security

OLS applies in embedded contexts the same way RLS does — the embed token's identity drives the OLS evaluation.

Capacity Sizing for Embedded Workloads

PBIE A-SKU sizing

A-SKU sizing is straightforward because each SKU corresponds to a fixed compute allocation:

SKU	Memory	Approximate concurrent active reports
A1	3 GB	~10
A2	5 GB	~20
A3	10 GB	~40
A4	25 GB	~100
A5	50 GB	~200
A6	100 GB	~400

These are starting-point estimates. Real concurrency depends on report complexity, dataset size, and query pattern.

F-SKU sizing for embedded

F-SKU sizing for embedded follows the same capacity-units model as the rest of Fabric. The starting point:

F-SKU	Capacity memory	Approximate embedded workload fit
F4	8 GB	Small ISV pilot or internal embedded
F8	16 GB	Mid-size ISV or substantial internal
F16	32 GB	Larger ISV scenarios
F32	64 GB	Large ISV with many active tenants
F64+	128+ GB	Large multi-tenant or heavy AI/Copilot

F-SKU sizing should be validated against the Fabric Capacity Metrics app during pilot.

Implementation Framework

For an ISV or enterprise standing up an embedded analytics architecture, EPC Group's typical pattern:

Weeks 1–3: Architecture and decision.

• Decision-framework workshop covering Copilot, Fabric features, pricing, multi-tenancy.
• Target architecture documentation.
• Pricing model selection and TCO modeling.
• Compliance overlay if regulated industry.

Weeks 4–7: Foundation.

• Capacity provisioning (PBIE or Fabric F-SKU).
• Azure AD application registration.
• Service principal provisioning and workspace access.
• Multi-tenancy pattern implementation.

Weeks 8–12: Integration.

• Power BI Embedded JavaScript SDK integration into host application.
• Embed token generation service in the host application backend.
• RLS / OLS / authentication integration.
• Theme, layout, and UX integration.

Weeks 13–16: Production hardening.

• Performance optimization (caching, dataset partitioning, aggregations).
• Capacity monitoring and alerting.
• Operational runbooks (failover, capacity expansion, tenant onboarding).
• Documentation handover.

The 16-week timeline is for a substantial ISV or enterprise deployment. Smaller deployments run shorter.

Common Pitfalls

1. Choosing PBIE A-SKU because it's familiar, then discovering Copilot is needed. Validate Copilot requirements early.
2. Workspace count exceeding capacity capability. A1 PBIE with 200 workspaces will struggle. Plan capacity sizing against tenant count.
3. Forgetting RLS in the embed token. Embed tokens without proper identity context bypass RLS — every user sees all data.
4. Hardcoding service principal credentials in the host application. Use Azure Key Vault or equivalent secret management.
5. Not modeling pause/resume against actual usage. Pause/resume saves money only if the off-hours are actually off. Some "off-hours" workloads (overnight batch, weekend reports) burn through the savings.
6. Mixing direct and embedded usage on the same capacity. Direct Power BI users and embedded ISV traffic on the same capacity can lead to noisy-neighbor problems. Separate capacities are typically the right pattern.

Frequently Asked Questions

What is Power BI Embedded?

Power BI Embedded is Microsoft's Azure-billed embedded-analytics service, allowing ISVs and enterprises to embed Power BI reports and dashboards into their own applications. End users do not need Power BI licenses; the host application owns the data access and presents the visuals through the Power BI Embedded JavaScript SDK.

What is Fabric Embedded?

Fabric Embedded is the newer Microsoft Fabric capacity offering supporting embedded scenarios. It uses Fabric F-SKU capacity-units billing rather than the PBIE A-SKU model and provides access to the broader Fabric feature set including Copilot and DirectLake on OneLake.

Can I use Power BI Copilot in PBIE A-SKU?

No, Copilot is not directly available on PBIE A-SKUs. ISVs and enterprises needing Copilot in embedded scenarios should use Fabric Embedded.

What is the pricing difference between PBIE and Fabric Embedded?

PBIE A-SKUs are Azure-billed hourly with pause/resume capability. Fabric F-SKUs are also pay-for-what-you-use with pause/resume. The cost crossover depends on workload pattern. Workloads with substantial off-hours often favor PBIE; workloads with 24×7 usage often favor F-SKU. Model both against expected patterns.

What is the application-owns-data pattern?

The application-owns-data pattern is where the host application authenticates as a service principal (not the end user) and presents reports to end users through embed tokens. End users do not need Power BI licenses. This is the standard pattern for ISV embedded analytics.

How does Row-Level Security work in embedded contexts?

RLS rules defined in the semantic model continue to apply. The embed token includes the end-user's effective identity, and the Power BI engine evaluates RLS against that identity. Users see only their authorized rows.

Can the embed token include a custom user identifier from my application?

Yes. The embed token's identity field accepts a custom identifier (typically the user's email or an opaque identifier from the host application's identity store). RLS rules can reference this identifier.

How do I size capacity for an ISV with hundreds of tenants?

Capacity sizing should be based on concurrent active users, not total tenants. A typical pattern: 10–20% of total users active at peak. Translate to capacity-size based on report complexity and dataset size. Validate during pilot before broad rollout.

What is the multi-tenancy isolation between workspaces?

Workspaces provide logical isolation. Data in one workspace is not accessible from another without explicit configuration. Service principal access is scoped per workspace. For higher isolation requirements (capacity-level or storage-level), the architectural pattern changes.

Can I use OneLake shortcuts to share data across tenant workspaces in Fabric Embedded?

Yes. OneLake shortcuts can surface shared reference data (product catalogs, dimension tables) into per-tenant workspaces without copying. Each tenant sees the shared data filtered by their RLS context.

How do I handle tenant offboarding cleanly?

Standard pattern: provision a tenant as a workspace, deprovision by deleting the workspace. The deletion removes all reports, datasets, and access bindings. For audit purposes, the deletion event is captured in the audit log; the workspace's content can be exported before deletion if retention is required.

Is Microsoft Entra External ID required for Fabric Embedded?

No. Service principal authentication remains the supported pattern. Microsoft Entra External ID is an option for scenarios where end-user identity federation is desirable (typically B2C scenarios) but is not required.

How does EPC Group support embedded analytics deployments?

EPC Group works with ISVs and Fortune 500 enterprises on Power BI Embedded and Fabric Embedded implementations. The standard pattern is a 16-week engagement covering decision framework, architecture, integration, and production hardening. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct embedded-analytics implementation experience across hundreds of engagements including regulated-industry ISV scenarios.

What is the typical Power BI Embedded JavaScript SDK integration scope?

The SDK integration is typically 2–6 weeks of engineering work depending on the host application's complexity, the customization required (theme, layout, navigation), and the embed-token generation service. EPC Group's pattern is to provide reference architecture and accelerator code that compresses the integration timeline.

Can I migrate from PBIE A-SKU to Fabric Embedded?

Yes. The migration is at the capacity level — workspaces move from the A-SKU capacity to a Fabric F-SKU capacity. The host application's embed-token generation logic typically requires minimal changes (the Power BI REST API surface is the same). Plan a pilot tenant migration first; validate; then migrate broader tenants.

Next Steps

If your ISV or enterprise is evaluating embedded analytics architecture, the practical next steps:

1. Run the decision-framework workshop covering Copilot, Fabric features, pricing, and multi-tenancy.
2. Model PBIE A-SKU and Fabric F-SKU pricing against expected workload patterns.
3. Inventory existing semantic models for migration complexity.
4. Provision a pilot capacity and integrate a representative report into the host application.
5. Engage a partner with deep embedded-analytics implementation experience to compress the planning timeline.

EPC Group has 29 years of enterprise Microsoft consulting experience and is Microsoft Solutions Partner with the core designations. We were historically the oldest continuous Microsoft Gold Partner in North America from 2016 until the program's retirement. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct embedded-analytics implementation experience across hundreds of engagements. To discuss your embedded architecture, contact EPC Group for a 30-minute discovery call.