Why Power BI Refresh Fails on Large SAP Extracts: Timeout Thresholds, Root Causes & Fixes

Connecting SAP to Power BI looks straightforward — connect to SAP HANA, SAP BW, SAP ECC or S/4HANA, build a semantic model, publish to the Power BI service, configure the gateway and schedule a refresh. The first few million rows refresh without problems.

Then the dataset reaches tens or hundreds of millions of rows, and you start seeing refresh timeouts, SAP query timeouts, gateway timeouts, out-of-memory errors, cancelled refreshes, SAP extraction taking hours — and the classic tell: refreshes that succeed in Power BI Desktop but fail in the service.

The important point: a large SAP-to-Power BI refresh failure is rarely caused by Power BI alone. It usually happens somewhere across the whole chain — SAP → extraction layer → network → gateway → Power Query → semantic model → capacity. Finding where the bottleneck sits is the key to fixing it.

Before changing any Power BI setting, identify the failure layer. A refresh can fail at several points:

This is why simply increasing a "Power BI refresh timeout" rarely solves the problem. There is no single universal threshold — the effective timeout depends on the connector, source, gateway, query execution, capacity and connection mode. A query might be terminated by SAP HANA, SAP BW, the network, the on-premises gateway, Power Query or the capacity. So do not start with "what is the Power BI timeout?" — start with "which component terminated the refresh?"

In Import mode, Power BI reads data from SAP and loads it into the model — but a 100-million-row refresh is not just "read 100M rows." Power BI also transfers, transforms, compresses columns, builds dictionaries, processes segments, updates relationships and commits the model. The larger the model, the greater the memory and processing.

Now picture a query of SELECT * FROM Billing against 200 million records. You are potentially extracting historical and unchanged rows, unnecessary and technical columns, text fields and high-cardinality attributes — and pushing all of it through the pipeline. The right question is: why extract 200 million rows if only 500,000 changed today? That leads straight to the biggest fix.

1. Stop full refreshes — use incremental refresh. Instead of pulling all 200M rows every morning, partition the model so only the data that changed is refreshed. Store, say, 10 years but refresh only the last 7 days. Microsoft documents incremental refresh as a way to partition data and refresh only the required period. It dramatically cuts SAP load, network traffic, gateway processing, refresh duration and capacity consumption. The catch: it works best when the source query can efficiently restrict by a date/time field (PostingDate, DocumentDate, CreatedDate, ChangedDate) — and that filter must reach SAP.

2. Protect query folding. Query folding means Power Query pushes transformations back to the source. You do not want SAP → 200M rows → Power BI → filter to 7 days; you want Power BI → generate a filtered query → SAP → return only 7 days (WHERE PostingDate >= …). That cuts data transfer, SAP workload, gateway traffic, Power Query memory and refresh time. Folding breaks with custom M functions, complex or unsupported transformations, early row-by-row operations, some native queries, certain joins and mis-placed type conversions — so test for folding rather than assuming it.

3. Do not extract every column. If the report needs sales document, customer, material, quantity, net value and posting date, do not also drag in 50 extra fields, long descriptions and technical metadata. Every extra column adds transfer, memory, compression work, model size and refresh time.

4. Watch high-cardinality columns. VertiPaq compresses repetitive values well but high-cardinality columns compress poorly. Customer Country might hold 20 values; Document Number might hold 100 million unique values — far more expensive. Review the model for high-cardinality columns you do not need.

5. Use a star schema. A large SAP model should rarely be one massive flat table. Build a FactSales with keys plus conformed dimensions (Customer, Material, Plant, Date, Salesperson, Company). Microsoft recommends star-schema modelling for Power BI semantic models where appropriate — it improves organisation, compression and query performance.

6. Keep SAP text fields in dimensions, not the fact. SAP holds huge amounts of descriptive data. Putting material number, descriptions, long descriptions, material group, product hierarchy, manufacturer and brand into the fact table bloats it. Keep those attributes in DimMaterial and join on the key.

7. Partition, and split historical from current. Partition large facts logically (2022, 2023, 2024, 2025, 2026) so only the required partitions process — the core reason incremental refresh is powerful. And not every record needs the same cadence: history (2020–2024) can refresh rarely, recent (2025) daily, and the last 7 days several times a day. Refreshing everything equally is far less efficient.

DirectQuery looks tempting — "we do not want to import 200M rows, so let us use DirectQuery." But it is not automatically the answer: every user interaction can generate queries against SAP, and with 500 concurrent users that becomes a very different workload. DirectQuery suits near-real-time needs, strong source performance, predictable query patterns, or volumes that make Import impractical — but prove it with performance testing.

Composite models can combine both — historical SAP data on Import and current SAP data on DirectQuery — giving fast historical analysis plus current operational status without forcing the whole dataset into DirectQuery. For many SAP workloads, a well-designed Import + incremental refresh model is a strong starting point.

Optimise the on-premises gateway. If SAP is on-premises and Power BI is in the cloud, the gateway is critical: Power BI service → gateway → network → SAP. Insufficient CPU, RAM or bandwidth degrades refresh. For enterprise use, consider a dedicated gateway server with enough memory, multiple nodes or a cluster, monitoring and network optimisation — and do not share it with unrelated workloads.

Do not confuse a gateway timeout with an SAP timeout. A Power BI timeout often just means the gateway is reporting that the upstream SAP operation did not finish in time. The fix may be to optimise the SAP query, not to change Power BI settings.

Reduce SAP query complexity. If the extraction itself is expensive, review joins, calculated fields, filters, aggregations, CDS views, BW queries, HANA calculation views and custom SQL. Push computation to the system best suited to it — do not force Power Query to do work SAP HANA or your data platform can do more efficiently.

HANA does not automatically make Power BI fast. "We use SAP HANA, so Power BI should be fast" is a myth. A powerful source cannot compensate for a poorly designed BI architecture — performance still depends on query design, volume, connector behaviour, network, gateway, transformation logic, model and capacity.

For large implementations, put a data platform between SAP and Power BI: SAP → data extraction → Azure Data Lake / Microsoft Fabric → lakehouse / warehouse → semantic model → Power BI. The platform handles historical storage, incremental ingestion, transformation, data quality, partitioning, multi-source integration, business logic and reusable datasets, so Power BI focuses on modelling, measures and visualisation.

This matters most when SAP is one of many sources. With SAP S/4HANA plus Salesforce, MES, WMS and IoT, direct point-to-point connections get hard to govern. Instead, land them all in Fabric or Azure, model Bronze → Silver → Gold, and drive Power BI from the Gold layer — so SAP is not asked to be the organisation’s analytical warehouse.

If you already run SAP BW, do not automatically bypass it. BW can provide SAP-specific modelling, business logic, aggregations, history and governed extraction, and Power BI can consume it through Microsoft’s supported SAP Business Warehouse connector (SAP ECC/S4 → BW → Power BI). But if your strategy is a modern cloud data platform, SAP → Fabric/Azure → enterprise data platform → Power BI may fit better. The right option depends on your SAP landscape and data strategy.

Sometimes the model is fine and the report is the problem. A page with 20 KPI cards, 10 charts, 5 tables, 4 slicers, 3 maps and several custom visuals can fire 30+ queries at the model on load. A technically optimised model can still feel slow if the report design creates excessive query concurrency — so trim the visuals per page.

Measure before you optimise. Do not guess. Use Power BI’s performance and monitoring tools to see query duration, DAX duration, visual rendering, data-source time, CPU, memory and refresh duration; on the SAP side, analyse HANA/BW query execution, workload, resource usage and extraction duration. The whole objective is to answer one question: where is the time actually being spent?

When a refresh fails, work through it in order rather than jumping to a fix:

• Power BI service — refresh start and failure time, error message, duration, dataset size
• Gateway — CPU, memory, connectivity, logs, concurrent refreshes
• SAP — query execution time, HANA/BW resource use, extraction performance, locks, expensive queries
• Power Query — query folding, transformations, joins, filters, custom M, data types
• Semantic model — model size, cardinality, relationships, column count, fact-table size, compression, DAX
• Capacity — CPU utilisation, memory, refresh concurrency, query workload, throttling

For a large SAP environment, a scalable target looks like: SAP ECC/S4HANA (via SAP BW and/or SAP HANA) → incremental extraction → Microsoft Fabric or Azure → Bronze → Silver → Gold → Power BI semantic model → incremental refresh → Power BI service. That separates the SAP operational workload from the enterprise analytical workload.

The single most important optimisation is to move the filter upstream. If you extract 100M rows every night just to filter down to 500,000 inside Power BI, that is an architecture problem. Aim for the filter to reach SAP (return 500K, not 100M) — or, better for enterprise scale, incrementally ingest into a lakehouse, partition it, curate a Gold dataset, and point Power BI at that.

A direct SAP → Power BI architecture can work very well for smaller environments. Move toward a data platform when you have hundreds of millions of SAP records, multiple SAP modules, multiple non-SAP sources, complex historical reporting, frequent refreshes, many semantic models, data-science or AI needs, enterprise governance or large concurrency. At that point the question is no longer "how do we make Power BI refresh faster?" but "should Power BI be extracting this data directly from SAP at all?"

Before buying more capacity or infrastructure, work through these:

• SAP — is extraction incremental? Are unnecessary fields excluded? Is the query optimised? Are CDS/BW/HANA views appropriate? Any unnecessary joins?
• Power Query — is query folding working? Are filters applied early? Are unnecessary transformations removed? Any custom functions forcing row-by-row processing?
• Semantic model — is it a star schema? Are unnecessary and high-cardinality columns minimised? Are dimensions separated from facts? Are aggregations appropriate?
• Refresh — is incremental refresh configured? Is the window appropriate? Are historical partitions excluded? Are many datasets refreshing at once?
• Gateway — is it dedicated, with enough RAM and acceptable CPU? Is a cluster needed?
• Power BI / Fabric — is capacity sufficient? Is refresh competing with interactive queries? Any memory pressure? Is monitoring enabled?

Large SAP-to-Power BI refresh failures are rarely solved by increasing a timeout. The real fix is usually a combination: incremental extraction, query folding, selective columns, star-schema modelling, partitioning, gateway optimisation, SAP query optimisation, capacity monitoring — and, at scale, a proper analytical data platform.

For smaller environments, SAP → Power BI may be perfectly adequate. For enterprise SAP analytics, SAP → Fabric/Azure data platform → curated data → Power BI semantic model is usually more sustainable. The goal is not just to make today’s refresh finish — it is to build an architecture that still works when 10 million rows becomes 100 million, 10 reports become 100, 50 users become 1,000, and daily reporting becomes near-real-time.

At MyData Insights, we assess and modernise SAP + Power BI architectures end to end — incremental refresh, semantic-model optimisation, Azure and Microsoft Fabric data platforms, SAP data integration and enterprise Power BI performance. The objective is not to fix one failed refresh; it is to design a scalable SAP analytics architecture that keeps performing as your data grows.