In this blog post, I want to show you how I architected a customer reporting solution using a single Microsoft Fabric F2 capacity and Power BI Embedded through Entelexos.

The two core subscriptions total USD $362 per month. That covers the reserved Fabric capacity and the Entelexos Basic subscription.

The reason I wanted to share this is to show that it is possible to engineer a cost-effective solution for smaller customers.

What is running on the F2?

The customer’s solution brings the data-loading and reporting workloads together on one Fabric capacity:

• 28 Python notebooks ingest data from an API and write it to a Lakehouse.
• One metadata-driven pipeline orchestrates ingestion twice a day, with failure notifications.
• One Import semantic model supports interactive reporting and paginated reports emailed to users.
• Entelexos provides the embedded reporting portal, with white labelling and Microsoft Entra ID authentication in this implementation.

The data flows from the API into the Lakehouse, then into the Import semantic model. Users access interactive reports through the embedded portal, while paginated reports support emailed reporting.

The Monthly Costs

That is USD $4,344 per year for these two subscriptions. For a smaller organisation with more than 40 users, it is a compelling starting point.

Personally, for a smaller organization with over 40 users, this is a very cost-effective solution.

Consumption

In this screenshot, background consumption is mostly around 10–20%, with interactive spikes remaining below the displayed capacity limit. This supports the sizing decision for the period shown; it is not a guarantee that every future workload will fit.

As data volumes, refresh requirements or concurrent usage grow, I would reassess the capacity. A small capacity is only cost-effective while it continues to meet the customer’s requirements. Engineering Solution

Due to this running at a small capacity, I had to ensure that it would be as efficient as possible when using the Capacity Units available.

I used Python notebooks to ingest the API data and write it to Lakehouse. For this workload, I found the default notebook settings efficient, with short execution times.

• 28 Python Notebooks ingesting data from an API and writing to the Lakehouse.
  • I have found that Python notebooks with their default settings are extremely efficient and can load a reasonable amount of data really quickly.
  • This means it is quick and consumes relatively small amount of CUs
  • 
• A single pipeline runs twice a day to ingest the data/
  • I use the pipeline to complete the orchestration to ensure that data is loaded efficiently using metadata.
  • Within the pipeline I also have put monitoring in place, so if something fails, I am notified immediately.
• A single Semantic Model using Import which is used for reporting and emailing out paginated reports.
  • Using the Import model allows for me to ensure that everything is optimized where possible to ensure that when DAX queries are being used it is very efficient in terms of CUs

Why the embedded approach matters

Why I chose to use Power BI Embedded

• Fabric F SKUs support Power BI embedding. The important distinction is how the reports are embedded, not just which capacity hosts them.
• In an app-owns-data embedded solution, report viewers do not need individual Power BI licenses. That is different from users opening reports directly in the Power BI service or using user-owns-data embedding on an F2, where viewer licensing requirements still apply.
• Authenticating to the portal with Microsoft Entra ID is not, by itself, what determines Power BI viewer licensing. The Power BI embedding configuration must use the appropriate app-owns-data approach.
• I chose Entelexos to provide the reporting portal. Its Basic deployment plan lists unlimited users, white labelling with a logo, and Microsoft-account OAuth authentication for $180 per month.
• Unlimited users are a portal-plan entitlement, not unlimited processing capacity. Concurrent report usage, model refreshes and ingestion still need to fit within the F2.

Summary

This implementation shows that an end-to-end Fabric reporting solution does not automatically require a large capacity. With the right workload, careful engineering and an embedded delivery approach, an F2 can be a practical and affordable option.

The value is in designing the whole solution together: ingestion, orchestration, monitoring, semantic modelling and report delivery. The low subscription cost is the outcome of those decisions.

If you are wondering whether your reporting environment could run more efficiently, contact me on FourMoo for a complimentary call. We can discuss your current architecture, usage and where there may be opportunities to reduce costs without compromising the reporting experience.

Thanks for reading.