Does Your Power BI Refresh Keep Failing Overnight?
Scheduled refresh times out, Power Query runs out of memory, and you find out when someone opens the dashboard. The cause is almost never Power BI. It is what Power BI is being asked to do.
The data warehouse automation platform trusted by data teams across industries
Does this sound familiar?
- The overnight refresh fails and you hear about it from whoever opened the report at 08:00.
- Power Query throws "out of memory" or the gateway times out, but never when you test it.
- A refresh that took four minutes in January takes fifty in October. Nothing in the report changed.
- You refresh manually before big meetings, because you do not trust the schedule.
The refresh is not failing for lack of memory. It is failing because it is doing work that was never meant to happen at refresh time.
What breaks: query folding
- When your M code folds, Power Query writes one SQL statement and the database does the work. Power BI just receives the result.
- When folding breaks, Power Query becomes the engine. It pulls raw tables across the network into memory and does the work itself.
- It breaks quietly: a merge, a custom column, a fuzzy match, an index column. No warning.
- It passes testing because your laptop runs it against a small table. Then the table grows.
Why it lands on you
- Those steps exist because you had to ship a report. The dimension you needed did not exist, or getting a column added meant a wait measured in months.
- The logic sits inside the
.pbix, invisible to everyone upstream. - You can change the report. You cannot change the warehouse.
The work is in the wrong place
- Merges, custom columns and fuzzy matches are integration work. In Power Query they run again on every refresh.
- It belongs in one central place: a data warehouse or data hub, built once and read by every report.
- If that sounds expensive, the estimate probably assumes hand built pipelines. A specialised automation platform generates them from a model, which changes both the cost and the time it takes.
What changes when the model arrives finished
Datavault Builder generates the vault and the star schema to run natively in the database you already have: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks or BigQuery.
- Your M code becomes
SELECT * FROM dim_customer, which folds by definition. - No merge, no parsing, no fuzzy match. That work is gone from the report.
- Refreshes finish in seconds, and finish predictably.
- Slowly changing dimensions are handled upstream as vault satellites, not approximated.
- The logic gains lineage, so “where did this number come from” has a visible answer.
What to ask for
Not “the refresh keeps failing”, but:
“Our Power Query steps are not folding, so the refresh pulls raw tables into memory every night. Can we get these as conformed dimensions and a fact table in the warehouse, so the report only reads them?”
If the answer is that modelling it properly would take a quarter of engineering time, that is exactly the objection Datavault Builder removes.
See It Working on Your Own Data
Book a free demo and bring the report that gives you the most trouble.
Three Steps to Numbers That Add Up
-
Extract the existing logic
Collect the calculations, joins and filters that live in your reports today.
-
Centralize it in one place
The logic moves into the warehouse model once, so every report reads the same definition.
-
Enjoy numbers that add up
Every report shows the same figure, and “where did this number come from” has a visible answer.
How Datavault Builder Hands Your Report a Finished Model
-
The model arrives finished
Datavault Builder generates the vault and the star schema to run natively in the database you already have: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks or BigQuery.
-
The work leaves the report
No merge, no parsing, no fuzzy match. That work is gone from the report.
-
Sources arrive integrated
Customers from the ERP, the CRM and the web shop are matched into one set of conformed dimensions. The join happens once in the warehouse, not again in every report.
-
History you can query
Every change is retained as it arrives, so you can report as-was as well as as-is, even where the source system overwrites its own records.
-
Every number has lineage
The logic gains lineage, so “where did this number come from” has a visible answer.
-
Changes handled upstream
Slowly changing dimensions are handled upstream as vault satellites, not approximated.
Customer Story: Porta
Recognized by BARC in The Data Fabric Survey 26
Meet Our Expert
Twenty minutes with our Sales Director, and an honest answer on whether this fits your situation.
Matt Collett
Sales Director
Great, pick a time that works for you:
Other Problems This Series Covers
-
Do Your Power BI Reports Show Different Numbers for the Same Thing?
Finance, Sales and Operations each built their own semantic model, and each is internally consistent. The definitions were never wrong in one place. They were never agreed in any place.
-
Is Your Power BI DirectQuery Report Slow on Every Click?
DirectQuery and Direct Lake promise live data. What you get is a thirty second visual and a compute bill nobody wants to explain. The mode is not the problem. The schema underneath it is.
-
Is Your Power BI DAX Getting Too Long to Maintain?
Two hundred lines of CALCULATE and FILTER is not a sign of advanced DAX. It is usually a sign that the warehouse never gave you the keys, the history or the grain you needed.