Most Power BI conversations start with a dashboard. That is usually where things go wrong. Dashboards are the visible output of an architecture, and when that architecture is unclear or unplanned, the dashboards reveal it: slow to load, inconsistent across teams, breaking on refresh, or showing numbers no one fully trusts. At Versich, we spend a lot of time untangling problems that began not in the visuals but in the decisions made much further upstream.
This guide explains how Power BI architecture actually works, from how data enters the platform to how reports reach end users. It covers connectivity modes, semantic modeling, refresh strategies, governance, gateway design, and the structural shifts introduced by Microsoft Fabric. Whether you are building a new analytics environment from scratch or trying to understand why an existing one is underperforming, this breakdown gives you the practical foundation you need.
What Power BI Architecture Actually Means
Power BI architecture is the end-to-end design of how data moves from its sources into models, and how those models serve reports, dashboards, and users. It is not just the layout of a single report. It includes decisions about:
- Where data lives and how Power BI connects to it
- Whether data is copied into Power BI or queried live
- How data is cleaned, shaped, and related inside a semantic model
- How reports are published, secured, and delivered to different audiences
- How the whole system handles refresh, scale, and governance
These decisions interact with each other. A team that chooses DirectQuery for freshness but has an unoptimised source database ends up with reports that time out under normal use. A team that builds 40 independent datasets each duplicating the same logic ends up unable to maintain consistent KPI definitions. Getting architecture right means thinking about the full pipeline, not just individual components.
The Core Architecture: Data Flow from Source to User
The conceptual flow through Power BI architecture has four stages, and understanding each one prevents the most common implementation mistakes.
Stage 1: Data Sources. Power BI can connect to over 200 source types natively, including relational databases, cloud platforms, SaaS tools, flat files, and streaming endpoints. The connector portfolio covers everything from SQL Server and PostgreSQL to Salesforce, SharePoint Online, Google Analytics, Azure Synapse, Snowflake, and BigQuery. For niche systems, custom connectors can be built using Power Query M extensions.
Stage 2: Transformation. Once connected, data passes through Power Query, where it is cleaned, filtered, shaped, and prepared before it enters the semantic model. Transformations are recorded as steps that replay on every refresh, which means heavy or poorly written transformation logic becomes a recurring refresh cost. The best practice is to keep Power Query lightweight and push heavier transformation work upstream into SQL views, stored procedures, or Dataflows Gen2 in Microsoft Fabric.
Stage 3: Semantic Modeling. The semantic model (previously called the dataset) is the analytical core. It holds tables, relationships, measures written in DAX, calculated columns, hierarchies, and security rules. This is where business logic lives. A well-built semantic model means measures are calculated consistently everywhere they appear, regardless of which report or which user is querying them.
Stage 4: Delivery. Reports are built in Power BI Desktop and published to the Power BI Service. From there, they are shared through workspaces, packaged into apps for specific audiences, or embedded into external applications. The Service handles refresh scheduling, collaboration, permission management, and deployment across development, test, and production environments.
Connectivity Modes and When to Use Each
The connectivity mode is one of the most consequential architectural decisions in any Power BI project. It determines how data is stored, how fresh it can be, what features are available, and how much load is placed on source systems.
| Mode | How It Works | Best For | Main Limitation |
|---|---|---|---|
| Import | Data copied into VertiPaq in-memory engine | Most BI scenarios; best performance | Requires scheduled refresh; dataset size limits apply |
| DirectQuery | Queries sent to source on every interaction | Very large or fast-changing datasets | Slower; limits some DAX features; source must be optimised |
| Live Connection | Connects to an existing external semantic model | Reusing governed enterprise models | No local transformation or modeling allowed |
| Composite / Hybrid | Mixes Import and DirectQuery in one model | Balancing freshness with performance | More complex to design and troubleshoot |
Import is the right default for the majority of BI use cases. It gives you full DAX capability, fast query performance through VertiPaq compression, and the ability to model data freely. DirectQuery should be reserved for scenarios where data volume genuinely exceeds practical Import limits or where near-real-time freshness is a hard requirement, not just a preference.
Composite models and hybrid tables are the more recent approach that allow a single model to mix modes. For example, a sales fact table can use Import for historical data while pulling today's transactions via DirectQuery, giving users full historical context alongside current figures. This is increasingly the architecture we recommend for clients who need daily refresh to include same-day data.
Semantic Modeling: Where Business Logic Lives
The semantic model is the most important component in Power BI architecture, and it is also the most frequently underbuilt. Reports are visible; the model is invisible. But the quality of every number, every filter, and every calculated value in your reports depends entirely on what is happening in the model underneath. Our guide on best practices for Power BI data modelling goes deeper on this, but the architectural principles are worth covering here.
A star schema is the standard structural approach for Power BI models. It places fact tables at the center, containing numeric measures and foreign keys, with dimension tables surrounding them for context. Dimensions cover entities like Date, Customer, Product, Region, and Department. Relationships run from dimension to fact in one-to-many joins.
The practical benefits of a star schema in Power BI are significant:
- VertiPaq compression improves dramatically on narrow, well-structured tables compared to wide flat files
- DAX measures calculate correctly and predictably within the filter context that star schemas create
- Models are easier to understand, maintain, and extend by other developers
- Report performance is faster because less data needs to be scanned per query
DAX measures carry the business logic that would otherwise be duplicated across dozens of reports. Revenue with returns excluded, gross margin excluding intercompany transactions, year-to-date comparisons that account for partial periods, all of this belongs in the model as reusable, certified measures, not in individual report visuals that each implement their own version.
Power BI Service and Workspace Architecture
Once content is built in Power BI Desktop, it is published to the Power BI Service, the cloud platform hosted on Microsoft Azure. The Service is where everything related to sharing, governance, refresh, and collaboration happens.
Workspaces are the organisational units inside the Service. Each workspace holds datasets, reports, dashboards, and dataflows. Access to a workspace is governed by four roles:
- Admin - Full control, including managing membership and deleting the workspace
- Member - Can publish content and manage other members, but cannot delete the workspace
- Contributor - Can publish and update content, but cannot manage membership
- Viewer - Can view and interact with content but cannot edit or publish
For teams that are serious about governance, workspace architecture matters. A pattern we use with clients is the three-workspace model: a Development workspace where work in progress lives, a Test workspace where content is reviewed before release, and a Production workspace that end users access. Promotion between environments is handled through deployment pipelines, which are available on Premium and Fabric capacities.
Power BI Apps sit on top of workspaces as a distribution mechanism. An app packages selected reports and dashboards from a workspace into a curated, navigation-friendly experience delivered to a specific audience with its own navigation structure. Finance users see their reports; operations users see theirs. The underlying workspace is not directly exposed, which keeps the development environment clean from the consumption layer.
The On-Premises Data Gateway: Hybrid Connectivity
Many organisations have data that cannot be moved to the cloud, either for regulatory reasons, network architecture constraints, or because the source systems are not internet-accessible. The on-premises data gateway solves this by creating a secure bridge between the Power BI Service and internal data sources.
The gateway is a Windows service that establishes an outbound connection to Azure Service Bus. There are no inbound firewall ports required. When a scheduled refresh or DirectQuery request arrives, the Service passes it through the Azure relay to the gateway, which then queries the on-premises source and returns the result.
Architecture decisions around the gateway are often where production systems break:
- Run enterprise gateways in cluster mode with at least two nodes for redundancy
- Monitor CPU and memory on gateway machines; sustained usage above 80% predicts failures under peak load
- Apply monthly updates to the gateway software; outdated versions are a common cause of silent refresh failures
- Do not share a production gateway with development and test workloads; resource contention causes unpredictable behaviour
- Consolidate to the minimum number of gateway clusters and avoid the sprawl of personal gateways in production environments
Refresh Architecture: Getting Data Freshness Right
Scheduled refresh is how Import models stay current. In shared capacity with Pro licensing, datasets can refresh up to eight times per day. On Premium or Fabric capacity, that limit rises to 48 refreshes per day, which for most scenarios means data that is current to within 30 minutes across business hours.
For large fact tables, refreshing the entire dataset on every cycle is wasteful and slow. Incremental refresh solves this by dividing the dataset into time-based partitions and only refreshing the recent ones, leaving historical data untouched. A five-year sales history configured with an incremental refresh policy that updates only the past 30 days can cut refresh duration by 90% or more, while still giving users full historical access.
Real-time or near-real-time scenarios require a different approach:
- DirectQuery - Reports query the source live on every interaction. No stored data, no refresh to manage, but performance depends entirely on the source system's speed
- Hybrid tables - Historical partitions use Import mode for speed; the current-day partition uses DirectQuery, giving both performance on historical data and freshness on today's transactions
- Streaming datasets - For genuine real-time use cases like call center dashboards or IoT monitoring, where data is pushed to Power BI via the REST API and visualised with a sub-minute lag
Security Architecture and Row-Level Security
Security in Power BI operates at multiple layers, and each layer needs to be thought through as part of the architecture, not added as an afterthought once reports are built.
Workspace roles control who can access the workspace and what they can do inside it. Row-Level Security controls what data a given user can see once they access a report. The two work together: workspace roles determine access to the report; RLS determines what the report shows when that person opens it.
RLS is defined in the semantic model using DAX filter expressions tied to security roles. Common patterns include:
- Region managers see data only for their region, based on their email address matched to a territory table
- Department heads see only their department's cost data
- Multi-tenant embedded deployments where each client sees only their own data
The practical implementation involves creating a security table in the model, relating it to fact and dimension tables, and writing DAX filters that use USERPRINCIPALNAME() or USERNAME() to resolve the current user's identity at query time. Always test RLS using the 'View as role' feature in Power BI Desktop before publishing, and test again with actual user accounts in the Service before going live.
Object-level security allows hiding entire tables or columns from users who should not see them at all, which is relevant for models that contain both sensitive and non-sensitive data served to different audiences.
Power BI and Microsoft Fabric: The Architecture Shift in 2026
The single most significant architectural change in Power BI over the past two years is its integration into Microsoft Fabric. Fabric is a unified analytics platform that consolidates data engineering, data warehousing, data science, real-time analytics, and business intelligence into a single SaaS environment built on OneLake.
For Power BI architecture, Fabric changes several assumptions:
- OneLake replaces separate storage. All Fabric workloads share a single storage layer. Power BI semantic models in Direct Lake mode read directly from OneLake Delta tables without importing or querying through a connector, combining Import-level performance with near-real-time freshness.
- Dataflows Gen2. The primary transformation layer in Fabric, replacing traditional Power Query Online workflows for most enterprise pipelines. Transformations run in the cloud, returning clean data to Power BI without gateway dependency.
- Deployment and CI/CD. Fabric's workspace model supports deployment pipelines and, as of 2026, CI/CD integration with Git repositories, making Power BI content manageable through the same version control practices used for code.
- Agent Skills for Power BI. Announced at Microsoft Build 2026, these allow AI agents to create semantic models and generate reports using natural language or screenshots, the beginning of agentic development in the BI space.
- Copilot in web modeling. Rolling out in mid-2026, this allows teams to improve their semantic models using natural language prompts directly in the Power BI Service, including renaming tables, creating relationships, and generating DAX measures.
Not every organisation needs Fabric today. If your current Power BI environment is stable and your data volumes are manageable, moving to Fabric is a considered migration rather than an urgent one. But understanding how Fabric changes the architecture is important for any team planning new environments or significant expansions, because the design decisions made now will either align with or work against the direction the platform is heading.
Embedding Power BI in External Applications
Power BI Embedded allows organisations to surface reports and dashboards inside their own applications or customer-facing products, without the end user needing a Power BI licence or seeing the Power BI interface.
Embedding works through the Power BI REST API and JavaScript SDK. Content renders inside an iFrame or JavaScript component in the host application, with the same interactivity as the native Service: filters, drill-throughs, slicers, and cross-highlighting all function normally.
Embedded architecture introduces specific design considerations:
- Token generation and management: each embed session requires a token, either a user-owns-data token using Azure AD authentication or an app-owns-data token using a service principal
- RLS must be implemented at the semantic model level and enforced through the embed token, so each user session sees only their permitted data
- Capacity planning is distinct for embedded workloads; concurrency requirements and user counts determine the Fabric capacity SKU needed
- Multi-tenant architectures where each client has their own data and their own isolated view require careful design of the RLS and token structure to prevent data leakage between tenants
Common Architectural Mistakes and How to Avoid Them
Most Power BI architecture problems we encounter at Versich trace back to a small set of recurring patterns. Recognising them early prevents a great deal of rework.
| Mistake | What Happens | How to Fix It |
|---|---|---|
| No star schema; flat wide tables | Slow queries, large model sizes, unpredictable DAX results | Restructure into fact and dimension tables with proper relationships |
| DirectQuery on unoptimised sources | Reports time out under normal use | Add database indexes, pre-aggregate in SQL views, or switch to Import with incremental refresh |
| Duplicate KPI logic across reports | Different reports show different numbers for the same metric | Centralise measures in shared certified semantic models |
| Personal gateways in production | Refresh fails when the gateway user's machine is off or they leave the organisation | Migrate to clustered enterprise gateways managed by IT |
| No deployment pipeline | Changes to production reports break live dashboards | Implement Dev/Test/Prod workspaces with deployment pipelines |
| RLS added after go-live | Security holes discovered late, requiring model restructure | Design and test RLS before the first report is published |
How We Approach Power BI Architecture Projects
Our Power BI consulting team treats architecture as the foundation of every engagement. We do not start with dashboards. We start with a discovery process that maps data sources, refresh requirements, user populations, and governance needs before a single report is designed.
The output of that discovery is an architecture specification: which connectivity mode applies to each data source, how the semantic model should be structured, where the gateway sits, how workspaces are organised, how security is implemented, and what the deployment pipeline looks like. This document becomes the reference point for everyone working on the project, preventing the divergent decisions that accumulate into technical debt.
We have helped teams migrating from other platforms build Power BI architecture that takes advantage of what the platform does well, rather than replicating the structure of the tool they are leaving. If you are moving from a different BI platform, our posts on the considerations involved in that process offer useful context:
- Migrating from Qlik to Power BI - what to expect from a Qlik to Power BI transition in terms of model design and data layer changes
- Transitioning from Tableau to Power BI - a practical breakdown of what translates between the two platforms and what requires a redesign
Conclusion
Power BI architecture is not a one-time setup task. It is a set of ongoing decisions that determine whether your analytics environment scales, stays consistent, and remains maintainable as the organisation changes. Getting the foundations right, the connectivity mode, the semantic model structure, the gateway configuration, the workspace design, and the security model, prevents the category of problems that most BI teams spend their maintenance cycles on.
The Microsoft Fabric integration and the agentic features announced at Build 2026 are accelerating the pace of change in what Power BI can do. The teams best placed to take advantage of those capabilities are the ones that already have a governed, well-structured architecture underneath.
If you want a review of your current Power BI environment or are starting a new implementation and want to design the architecture correctly from day one, get in touch with our team. We work with organisations at every stage of the Power BI journey, from initial setup to large-scale enterprise deployments.
