Tableau Hyper Files to Power BI: Converting Extracts, Refresh, and Model Size

A .hyper file is a Tableau extract: a compressed, columnar snapshot of data that Tableau's engine queries locally. It is a cache, not a source system, and Power BI cannot open one. The file connectors in Power BI Desktop are Excel, Text/CSV, XML, JSON, Folder, PDF, Parquet and SharePoint folder, with no Tableau format in the list, so converting a Hyper file means choosing between two routes: point the new model at the original source system, usually the right answer, or read the extract with Tableau's Hyper API and land it in a format Power BI can import.

What a Tableau extract maps to in Power BI

Should you convert the extract or reconnect to the source?

Reconnect whenever the upstream system still exists and you can get credentials. An extract is not a faithful copy of a source table: Tableau's extract settings offer filters, an Aggregate data for visible dimensions option with date roll-up, and a choice between all rows, a sample, or the top N rows, any of which may already be baked into the file you hold. Reconnecting also restores what Power BI needs later: a query that folds, a real date column to partition on, and a refresh path that does not depend on a file on somebody's laptop.

Convert from the file only when there is nothing to reconnect to: the source was decommissioned, the spreadsheet behind an ad-hoc upload is gone, or credentials will not arrive inside the migration window. Even then it is a bridge and not a destination, because a table loaded from a one-off export cannot be refreshed by anyone. Either way, keep the extract as your validation baseline: its totals are what the Tableau dashboards actually showed.

How to read data out of a .hyper file

Start with unpacking, because it tells you what you have. Tableau's own instruction is to rename a packaged workbook with a .zip extension and open it, so unzipping a folder of workbooks cheaply reveals which ones carry embedded data. The Hyper API is the scriptable route, shipping for Python, C++ and Java, opening existing files and querying them with SQL. Prefer Parquet over CSV on the way out: Power BI reads it natively and it carries column types, sparing Power Query from guessing dates and decimals.

One caveat applies to every export route: Tableau warns that an export may exclude some table calculations and level of detail expressions, because those are computed in the view rather than stored as data. That is DAX work, not a gap in the data move, covered in LOD expressions to DAX and table calculations to DAX.

How extract refresh becomes semantic model refresh

Tableau's incremental extract refresh watches a column you nominate and appends the rows above its last value. Power BI is declarative instead: create two Power Query date/time parameters with the reserved, case-sensitive names RangeStart and RangeEnd, filter the table with them, then set an archive period and a refresh period. The service creates and rolls the partitions itself, refreshing recent ones and dropping history as it ages out.

Three requirements decide whether that works. The filter has to fold to the source, or the engine retrieves every row and filters locally, defeating the policy. The parameters must be the date/time type even when the table is partitioned on an integer key such as yyyymmdd, which you convert inside the query. And the source has to be a live system, because a static CSV exported from an extract has nothing to filter incrementally. Incremental refresh itself is supported on Pro, Premium per user, Premium and Embedded; only the real-time DirectQuery partition is Premium-only.

Budget the windows too: a refresh must finish within two hours on shared capacity and five on Premium, shared capacity allows eight scheduled refreshes a day against 48 on Premium or Fabric, and on-premises sources need an enterprise gateway.

Model size and the 1 GB limit

The default size limit for a semantic model is 1 GB, and Fabric capacities, Premium per user and Embedded go past it once Large semantic model storage format is on, when the ceiling becomes the capacity size. A model published from Power BI Desktop is separately capped at a 10 GB upload.

Those limits sound tight next to a multi-gigabyte extract and usually are not: Microsoft's guidance for Import models puts VertiPaq compression at roughly 10x, so 10 GB of source data can land near 1 GB. Columns and cardinality drive the result rather than row count, and extracts are the bad case, because the Tableau author included every column of every table and nobody revisited it. Dropping unused columns is the highest-yield change available at import.

What Antares does with extracts and Hyper files

Antares never touches the data inside an extract: analysis and conversion read metadata only, never business data. Moving rows between platforms is a data-platform job, not a dashboard-migration one.

What the Analyzer contributes is the inventory behind the decision above. It reads every data source in every workbook, records whether each is live or extract-backed, and captures what the connection points at. So before anyone opens a file, you know which dashboards can be repointed at a system that still exists and which are backed only by an extract with no reachable upstream. That second group is usually small, and it is where migration estimates go wrong. Run the free Analyzer for your own workbooks.

Related reading: extracts to Power BI dataflows and data sources to Power BI datasets. Primary sources: Tableau's extract format notes and export documentation, the Hyper API installation guide, and Microsoft's data refresh reference.