Power BI Embedded: custos, dimensionamento de capacidade e quando é melhor criar seus próprios painéis

For a SaaS product that needs customer-facing dashboards, Power BI Embedded typically costs $750–$3,500 per month in capacity for the first few hundred active analytics users — and replaces what is realistically a $150,000–$400,000 first-year engineering effort to build an equivalent custom dashboard layer with charting libraries, a query API, caching, and export features. The break-even logic is straightforward: below roughly 10,000 monthly analytics users, embedding almost always wins on total cost; at very large scale, or when dashboards ARE your product's core differentiation, custom builds start to justify themselves.

This guide gives you the 2026 numbers: what each SKU costs, how to size capacity against real user loads, where hidden costs hide, and an honest build-vs-buy framework for ISV and SaaS decision-makers.

Key Takeaways

• Entry pricing: an A1/F8-class capacity runs roughly $750–$1,100 per month pay-as-you-go; most production ISV deployments land on F16–F64 ($2,100–$8,400+ per month, with ~40% reserved-instance discounts)
• Embedded capacity is priced per capacity, not per end user — your customers need no Microsoft licenses under the "app owns data" model
• A sensible sizing starting point: one F8 handles roughly 100–300 concurrent-ish viewers of well-optimized import-mode reports; bad data models cut that by 5–10x
• A-SKUs (Azure, hourly, pausable) suit dev/test and spiky workloads; F-SKUs (Fabric) are the strategic SKU family Microsoft is investing in
• Building an equivalent custom analytics layer costs $150k–$400k+ in year one and 1–2 permanent engineers thereafter — the comparison most teams underestimate
• The biggest cost lever is not the SKU — it is your data model; optimization routinely halves required capacity
• Choose custom builds when analytics is your product's core IP, you need pixel-perfect UX control, or your scale makes per-capacity economics worse than raw compute

---

How Power BI Embedded Pricing Works in 2026

Power BI Embedded is sold as dedicated capacity — a pool of compute that renders reports for your application's users. Two SKU families matter:

Indicative 2026 monthly prices (US regions, list):

Prices vary by region and shift over time — treat these as planning numbers and confirm against the Azure calculator. The structural points are stable: capacity is the unit of purchase, reserved instances save roughly 40%, and small F-SKUs (F2–F32) have made the entry point dramatically cheaper than the old P1-only world.

Two licensing notes that trip teams up. First, under the "app owns data" embedding model (your app authenticates via a service principal and your customers never see Microsoft), end users need zero Power BI licenses — but your report developers each need a Pro license ($14/user/month). Second, very small F-SKUs are tempting but have model-size memory limits (an F2 caps semantic models at around 3 GB); size against your largest dataset, not just user count.

Capacity Sizing: A Practical Method

Microsoft's guidance is famously abstract ("it depends on workload"), so here is the method we use on real ISV projects.

Step 1 — Estimate render concurrency, not user count. Capacity consumption is driven by report renders and queries, not registered users. A typical SaaS pattern: 10,000 monthly active users produce 500–1,500 daily analytics sessions, which produce 20–60 truly simultaneous render bursts at peak. Concurrency is usually 1–3% of daily actives.

Step 2 — Apply per-render cost. A well-built import-mode report page consumes a few seconds of a fraction of a v-core per interaction. As rough planning figures for optimized reports:

Step 3 — Stress-test before committing. Run a load test against an A-SKU (hourly billing, pause when done) using realistic report interactions, watch the capacity metrics app for throttling and interactive delays, then buy the F-SKU reservation one size above your observed peak.

Step 4 — Re-test after model optimization. This is the step that saves money. The difference between a star-schema import model with aggregations and a sprawling DirectQuery model with bidirectional relationships is routinely 5–10x in capacity consumption. We have cut clients from F64 to F16 — a ~$45,000 annual saving — purely through performance optimization work on the semantic model, with zero feature loss.

Multi-tenancy choices also shape capacity. Separate-workspace-per-tenant with a shared model and row-level security is the standard pattern up to hundreds of tenants; very large ISVs shard tenants across multiple capacities and can pause low-usage shards. Design this before onboarding tenant number two — retrofitting tenancy models is painful.

The Build-vs-Buy Math Nobody Writes Down

The alternative to embedding is building a dashboard layer yourself: a charting library (ECharts, Highcharts, AG Charts), a query/aggregation API, a caching tier, filter and drill interactions, scheduled exports, and per-tenant security. Teams consistently underestimate this because the demo is easy — a chart on a page takes a day. The product is hard: the long tail of cross-filtering, export to Excel/PDF, time-zone handling, drill-through, mobile layouts, and "can I slice this by region?" requests is where the cost lives.

Three-year total cost for a mid-size ISV (say, 20,000 MAU with moderate analytics usage): roughly $700k–$1.2M custom versus $150k–$350k embedded. The gap is large enough that the decision is rarely actually about cost — it is about the strategic questions below.

Choose custom when: the analytics experience IS your product (you are selling analytics itself, not a product that has analytics); you need interaction patterns Power BI cannot express; your scale is so large that per-capacity costs exceed equivalent raw compute plus an amortized engineering team; or hard requirements (offline, air-gapped deployments) rule out the service.

Choose Embedded when: analytics is a feature, not the product; speed to market matters; your team is small; your customers ask for export-to-Excel and self-service slicing (brutal to build, free to embed); or your stack is already Azure-adjacent.

A hybrid pattern we increasingly deploy: custom-built KPI cards and summary widgets (cheap, fully branded) on the main product screens, with Power BI Embedded behind an "Analytics" tab for deep interactive reporting. You get pixel-perfect brand surfaces where they matter and a full BI engine where depth matters.

Hidden Costs and How to Avoid Them

• Developer licenses and environments: report authors need Pro; keep a paused A-SKU for dev/test instead of a second F reservation.
• Data pipeline work: Embedded renders what your model contains — getting operational data into an analyzable shape is its own workstream, typically a third of project effort. Budget data modeling as a first-class line item.
• Capacity throttling surprises: Fabric's smoothing and throttling model means sustained overload degrades politely then hard. Set capacity-metric alerts at 70% before customers feel anything.
• Print/PDF export at scale: export operations are expensive capacity-wise; queue and throttle them in your app layer.
• Tenant onboarding automation: workspace provisioning, RLS role assignment, and deployment pipeline automation via the REST APIs is a build-once investment that separates smooth ISVs from ticket-driven chaos.

Frequently Asked Questions

Do my customers need Power BI licenses to view embedded dashboards?

No. Under the "app owns data" model — the standard for ISV and SaaS scenarios — your application authenticates with a service principal, generates embed tokens, and your customers view reports inside your product with no Microsoft identity or license at all. You pay for capacity; they just use your app. Only your internal report developers need Pro licenses.

What is the realistic minimum monthly cost to run Power BI Embedded in production?

For a genuine production workload: roughly $600–$1,100 per month — an F8 (or A1-class) capacity, with reserved pricing pulling that toward the low end, plus a couple of Pro licenses for developers. An F2 at $263/month ($156 reserved) can technically serve tiny workloads but its memory ceiling (~3 GB models) and limited headroom make it a pilot SKU, not a scale plan. Add a paused dev A-SKU for a few dollars of actual usage per month.

A-SKU or F-SKU — which should a new project pick in 2026?

Start development on an A-SKU because hourly billing and pausing make experimentation nearly free. For production, default to F-SKUs: they are Microsoft's strategic family, unlock Fabric workloads (lakehouse, pipelines, notebooks) you may want for the data layer anyway, and offer reserved pricing. A pure-embedded ISV with extremely spiky traffic is the main case where production A-SKUs still make sense.

How many users can one capacity actually support?

Measured in registered users: often tens of thousands, because capacity consumption tracks concurrent report interactions, not accounts. A well-optimized report set on an F8 typically sustains 15–40 simultaneously active sessions, which for typical SaaS engagement patterns maps to 5,000–30,000 monthly active users. The honest answer is that your data model quality swings this by 5–10x in either direction — load-test with your real reports before buying reservations.

Can we embed dashboards per customer with isolated data?

Yes — this is the standard multi-tenant pattern. The common architecture is one shared semantic model with row-level security roles mapped to tenant IDs in the embed token, or separate workspaces per tenant for stronger isolation and per-tenant customization. RLS-on-shared-model scales operationally better; workspace-per-tenant suits high-touch enterprise customers. Most ISVs end up with a mix, automated through the Power BI REST APIs.

When does building our own dashboard layer actually become cheaper?

Two scenarios. First, extreme scale with shallow analytics: if millions of users each view one simple pre-aggregated chart, serving cached JSON to a charting library beats paying for a BI engine you barely exercise. Second, when analytics is your core product and differentiation lives in the interaction model itself — then the $300k+ per year of engineering is not overhead, it is your product investment. For analytics-as-a-feature SaaS below roughly 10,000 monthly analytics users, custom builds almost never win the three-year math.

---

Scope Your Embedded Analytics Project With Us

ECOSIRE designs and ships Power BI Embedded integrations for ISVs and SaaS teams — capacity sizing backed by load tests, multi-tenant architecture (RLS and workspace strategies), embed-token services, and the semantic-model engineering that keeps your capacity bill small. We will also tell you plainly if a custom build or hybrid serves you better; the build-vs-buy workshop is the first thing we run.

Explore our embedded analytics service and performance optimization service, or contact us for a free sizing estimate — bring your user counts and we will bring the capacity math.