Power BI Limitations

1. Semantic model size limits (Import mode): Pro workspaces cap semantic models at 1 GB compressed per model. The underlying uncompressed source data can be much larger due to VertiPaq compression (commonly 5-10x), so a 1 GB model may represent 5-10 GB of raw data. Premium and Fabric capacities allow models to exceed this limit when the large dataset storage format is enabled, but total capacity memory is shared across all models on the node. DirectLake and DirectQuery avoid the limit entirely by not importing data.

2. Scheduled refresh limits: Import mode semantic models can be refreshed up to 8 times per day on Pro workspaces, and up to 48 times per day (every 30 minutes) on Premium, PPU, or Fabric capacities. For true real-time or near-real-time data, scheduled refresh is insufficient — DirectQuery, DirectLake, or Fabric EventStream (Real-Time Intelligence pipeline) are the appropriate alternatives.

3. DirectQuery performance dependency: In DirectQuery mode, every visual render issues a live query to the source system. Report performance is therefore bounded by source database latency and concurrency limits. A slow or overloaded source database produces slow reports, and this cannot be mitigated within Power BI alone.

4. Limited R and Python visual support: R and Python visuals render via local script execution and are not supported in the Power BI mobile app. They are also restricted or disabled in certain embedding scenarios (publish-to-web, some sovereign cloud configurations), which limits their use in broadly distributed reports.

5. DAX complexity ceiling: DAX is a highly capable analytical expression language, but it is not a general-purpose programming language. Complex statistical modeling, ML inference, iterative algorithms, or procedural logic cannot be expressed cleanly in DAX. These workloads belong in external tools — Python, R, Azure ML, or Spark — with results surfaced in Power BI as pre-computed columns or measures.

6. Custom visual governance: Custom visuals obtained from AppSource introduce a governance and security review burden. Enterprise environments that restrict visuals to an organizational store or to Microsoft-certified visuals only give development teams a constrained palette, which can require workarounds or license upgrades to address.

7. Cross-report sharing requires compatible access: Reports that reference a shared semantic model require consumers to have access to the workspace or app where both the report and the semantic model reside. Distributing semantic models across workspace or tenant boundaries requires careful Fabric capacity planning and entitlement management.

8. TMDL and source control still maturing: TMDL (Tabular Model Definition Language) for git-based source control of semantic models shipped in 2023-2024, and Fabric Git integration with deployment pipelines provides a path to CI/CD. However, this ecosystem is still evolving and is not yet as mature or well-tooled as traditional software delivery pipelines — branching strategies, automated testing, and pipeline templates are areas of active development.

9. Object-level security (OLS) requires Premium or PPU: Hiding specific tables or columns from users based on their role (object-level security) is not available in Pro workspaces. Organizations that need column-level data access control must have Premium Per User, Premium capacity, or Fabric capacity.

10. No native version control in Desktop: Power BI Desktop saves reports as binary .pbix files, making meaningful git diff-based code review impractical. Fabric Git integration using TMDL partially addresses this for semantic models published to a Fabric workspace, but local Desktop development remains outside this workflow, creating a gap in version control coverage for teams iterating quickly in Desktop.

Import mode semantic model limits

• Power BI Pro: 1 GB compressed per semantic model in a shared Pro workspace. Due to VertiPaq column-store compression (typically 5-10x), a 1 GB model can represent 5-10 GB of raw source data. This limit is enforced on the compressed, in-memory footprint.
• Premium Per User (PPU): the same 1 GB per-model compressed limit applies, but PPU unlocks Premium features such as incremental refresh, paginated reports, and deployment pipelines.
• Power BI Premium (P-SKUs) and Fabric (F-SKUs) with large dataset storage format enabled: models can exceed the 1 GB limit. The ceiling is the total available memory on the capacity node, shared across all models loaded simultaneously. An F64 Fabric SKU provides 512 GB of capacity RAM; larger SKUs (F128, F256, F512) scale proportionally. Microsoft publishes per-SKU memory allocations in Fabric documentation.

Workspace and OneLake limits

• OneLake, the Fabric unified storage layer, is built on Azure Data Lake Storage Gen2 and has no hard cap on total storage. Organizations pay for what they use; there is no pre-provisioned storage quota to manage.
• Individual files in OneLake follow Azure ADLS Gen2 limits — no practical file size constraint for typical analytical workloads.

DirectQuery and DirectLake

• DirectQuery: no data is stored inside Power BI. The applicable size limits are those of the source database or data warehouse, not Power BI itself.
• DirectLake: the semantic model reads Delta Parquet files directly from OneLake without a full import. There is no fixed file size cap; the effective limit is the Fabric capacity's available memory for caching hot data segments. DirectLake was introduced specifically to sidestep Import mode size limits while delivering near-Import query performance — queries that miss the cache fall back to DirectQuery against OneLake automatically.

Row limits (export and rendering constraints)

These limits govern how much data can be extracted from a visual, not how much the model stores:

• Export to Excel from a visual: up to 150,000 rows.
• Export to CSV from a visual: up to 30,000 rows in shared (Pro) capacity; higher limits apply in Premium capacity.
• These are presentation and export constraints, not reflections of the model's storage capacity.

Refresh payload

Each individual table loaded during a scheduled or on-demand refresh can be up to 2 GB uncompressed before the VertiPaq engine compresses it into the model. Tables larger than this must be handled through incremental refresh partitioning, which reloads only the affected partitions rather than the whole table in a single operation.

Import mode (scheduled refresh)

• Free and Pro workspaces: up to 8 scheduled refreshes per day per semantic model.
• Premium Per User (PPU), Premium (P-SKUs), and Fabric (F-SKUs): up to 48 scheduled refreshes per day, allowing a minimum scheduled interval of 30 minutes. The Power BI Service scheduler does not support sub-30-minute intervals through the UI.
• Refresh windows can be configured to avoid peak hours, and specific days of the week can be excluded.

API-triggered (on-demand) refresh

Import mode models can be refreshed on demand via the Power BI REST API or Fabric REST API, independently of the scheduled refresh cadence. This enables event-driven patterns — for example, a Data Factory pipeline or Fabric Pipeline triggers a semantic model refresh immediately after a data load completes, rather than waiting for the next scheduled window.

• Rate limit: the API enforces a per-dataset-per-hour refresh call limit. For most capacities this is currently 8 API-triggered refreshes per hour. Exceeding this limit returns a 429 error.
• API-triggered refreshes count separately from the daily scheduled refresh quota on Premium/Fabric but are subject to their own rate limits.

DirectQuery mode

DirectQuery semantic models do not use scheduled data refresh — every visual query hits the source system live, so the data is always as current as the source allows. A metadata refresh (to detect schema changes in the source) can be triggered separately, but this is not a data refresh.

DirectLake mode (Fabric)

DirectLake models read directly from Delta tables in OneLake. As new data is written to OneLake by Spark jobs, pipelines, or streaming ingestion, it becomes available to Power BI without any scheduled refresh step in Power BI itself. Availability is governed by when Delta transactions are committed to OneLake, not by a Power BI refresh schedule.

DirectLake uses a "framing" concept: the model reads the latest committed Delta checkpoint at query time. Cached column segments are refreshed from OneLake as needed. Automatic schema detection can be configured so that new columns added to the Delta table are picked up without manual intervention.

Streaming and real-time intelligence

For sub-minute real-time data requirements, classic Power BI streaming datasets (push datasets) are limited in capability and are being superseded by Fabric Real-Time Intelligence. The recommended 2026 pattern is:

1. Ingest event data via Fabric EventStream.
2. Land it in a Fabric KQL Database (Real-Time Database) or Lakehouse.
3. Query it from Power BI via DirectQuery or DirectLake.

This architecture decouples the ingestion cadence from the Power BI refresh cycle and supports latencies measured in seconds rather than minutes.

Data volume

If source data exceeds the 1 GB compressed Import mode limit and the organization has only Pro licenses, the options are: switch to DirectQuery against a well-indexed source database, move to a Fabric or Premium capacity and enable large dataset storage, or use DirectLake if the data resides in OneLake. For datasets in the tens or hundreds of billions of rows, Power BI is best positioned as a visualization and semantic layer sitting on top of a purpose-built analytical database (Azure Synapse, Azure Data Explorer, Snowflake, Databricks) rather than as the data store itself.

Refresh frequency and real-time requirements

Import mode with 8 refreshes per day (Pro) is appropriate for data that is acceptable to be hours old. If data must be current within minutes, DirectQuery against a fast source, DirectLake on a continuously updated OneLake table, or Fabric EventStream into a KQL Database are the viable paths. If sub-second latency is required, Power BI may not be the right frontend at all — Azure Data Explorer dashboards or custom web UIs backed by a streaming store are better suited, with Power BI used for historical and trend analysis alongside them.

Advanced analytics and machine learning

Power BI is not designed for in-model ML training or complex statistical computation. The correct pattern is to run model training and inference externally — in Azure Machine Learning, Databricks, or Python/R scripts in Fabric notebooks — and surface pre-computed predictions or scores as columns in the semantic model. Power BI then handles visualization and filtering of those results rather than computing them.

Pixel-perfect and paginated output

Power BI interactive reports use a flexible canvas layout that adapts to screen size. This is not suitable for documents requiring precise print pagination, fixed column widths, or multi-page table continuation. Power BI Paginated Reports (available on Premium, PPU, and Fabric) handle pixel-perfect layouts and are the right choice for invoices, regulatory filings, and operational reports that must print exactly. However, paginated reports require a separate authoring tool (Power BI Report Builder) and a different skillset from interactive report design.

Governance and object-level security

If column-level or table-level security (OLS) is a requirement and the organization has only Pro licenses, Power BI cannot satisfy it — OLS requires Premium Per User or Premium/Fabric capacity. In this situation, it is worth evaluating whether Azure Analysis Services (which supports OLS at all service tiers) is more appropriate, or whether upgrading to PPU is justified by the security requirement alone.

Licensing cost relative to user count

Pro is a per-user license; Premium and Fabric are per-capacity licenses. For organizations with a small number of report authors but a large population of consumers (view-only users), a Fabric or Premium capacity is typically more cost-effective because consumers can view published content without holding a Pro license. The break-even point depends on the number of consumers and the capacity SKU selected, but large consumer audiences almost always favor a capacity-based model.

Conclusion

Power BI is well suited to self-service analytics, enterprise-scale semantic modeling via Fabric, and integrated Microsoft ecosystem reporting. Where it falls short — ultra-low-latency dashboards, heavy ML workloads, or pixel-perfect paginated documents — the right response is to use specialized tools alongside Power BI rather than to replace it entirely. Power BI's strength is in serving as a unified semantic and visualization layer that connects to these specialized systems, not in trying to replicate their capabilities internally.

Power BI has several limitations that are easy to miss until they cause real problems in production or collaborative environments.

Binary .pbix format makes source control painful

The .pbix file is a binary ZIP archive. It cannot be meaningfully diff'd in git — a one-line DAX change produces an unreadable binary diff. This makes collaborative development, code review, and change auditing difficult. Many teams only discover this limitation when they hit a merge conflict or need to explain what changed between two versions.

Microsoft's TMDL (Tabular Model Definition Language), available through Fabric Git integration, partially addresses this for the semantic model layer by serializing the model as human-readable text files. However, report layout files still use a JSON-based format that is verbose and hard to review. For teams needing true version control, the current best practice is Fabric Git integration combined with Tabular Editor for the model layer — but this requires a Fabric capacity and a shift in tooling.

Calculated columns bloat in-memory model size

Developers coming from a SQL background often reach for calculated columns as a natural equivalent to computed columns in a table. The key difference: each calculated column is materialized and stored in VertiPaq memory for every row in the table. A calculated column on a 50-million-row fact table will occupy significant RAM regardless of whether any report queries it.

Measures achieve the same aggregation logic without consuming any memory outside of query execution time. The general rule: use calculated columns only when you need to slice or filter by the computed value (i.e., it needs to exist as a real column). For anything that results in an aggregated number on a visual, use a measure instead.

Query folding breaks silently

Query folding is the ability of Power Query to translate M transformation steps back into a native source query (SQL, OData, etc.), so the source database does the heavy lifting rather than Power Query's local engine. When folding breaks, the entire table is loaded into memory and transformations run locally — often dramatically slowing refresh on large tables.

The problem is that folding breaks silently. Common culprits include adding a custom column with conditional logic, certain merge join types, accessing non-relational sources mid-query, or using functions that have no native SQL equivalent. There is no prominent warning that folding has stopped. Developers typically don't notice until they observe a refresh that takes 10 minutes instead of 30 seconds. The View Native Query option in Power Query Editor (when enabled) and the Query Diagnostics feature are the primary ways to verify whether folding is active.

DirectQuery imposes a 1-million-row cap per visual query

In DirectQuery mode, each visual query is capped at 1 million rows returned by default. This limit exists to protect the source database from runaway queries, but it can catch teams off guard when building detail tables, drill-throughs, or export scenarios that need to surface more records. The cap is configurable via the DirectQueryResultRowLimit setting in some contexts, but the default behavior is to silently truncate the result set rather than raise a visible error to the report user.

RLS is bypassed via the XMLA endpoint for admin users

Row-level security (RLS) is enforced at query time for users consuming reports through Power BI Service. However, when a user with Admin or Contributor rights on the workspace connects to the semantic model via the XMLA endpoint — using external tools such as Excel Analyze in Excel, DAX Studio, Tabular Editor, or third-party BI tools — RLS is bypassed entirely. The connecting identity sees unfiltered data.

This is by design, not a bug, but it is a governance gap that is frequently underdocumented. Organizations with strict data access controls need to explicitly account for this: either restrict workspace admin rights to a small set of trusted users, or document that XMLA-connected tools bypass RLS.

Time intelligence DAX requires a complete, marked date table

Functions like TOTALYTD, SAMEPERIODLASTYEAR, DATEADD, and PARALLELPERIOD have a strict dependency: a dedicated date table that (1) has no date gaps across the full year range used by the fact data, (2) is explicitly marked as a Date Table in the model, and (3) has an active relationship to the fact table on a date key.

If any of these conditions are not met, time intelligence calculations will return incorrect results or blanks — often without an obvious error message. A common mistake is using a date dimension that spans only the years present in the fact data but has gaps around weekends or holidays, or forgetting to mark the table as a Date Table after building it. The silent failure mode makes this particularly difficult to diagnose.

Composite models have non-obvious filter propagation behavior

Composite models allow mixing Import and DirectQuery tables in a single semantic model. However, filters do not automatically propagate across the Import/DirectQuery boundary in all configurations. A filter applied to an Import-mode dimension table may not propagate to a DirectQuery fact table unless the relationship between them is explicitly configured with the correct cross-filter direction.

Bidirectional relationships in composite models introduce additional risks: they can create query ambiguity where DAX has multiple valid filter paths, leading to incorrect aggregations or performance problems. Teams migrating from pure Import models to composite models often underestimate how much relationship configuration review is required.

Paginated Reports are a separate product and skillset

Power BI Desktop produces interactive reports optimized for exploration. Pixel-perfect, printable, multi-page operational reports — invoices, regulatory filings, statements — require Power BI Report Builder (or SSRS), a separate authoring tool with a different design paradigm. The skillset does not transfer directly: Report Builder uses datasets, parameters, tablix regions, and expressions rather than the drag-and-drop visual model of Desktop.

Organizations that assume Power BI handles all reporting needs are often surprised when they need a formatted document-style report. Paginated Reports also require Premium, PPU, or Fabric capacity to publish and share through Power BI Service.