Where does the storage bill land for Link to Microsoft Fabric?

On Dataverse, not on Azure. Link to Microsoft Fabric does not copy your data into a storage account you own and bill you for the blob. Dataverse maintains an internal managed OneLake store and shortcuts it into your Fabric lakehouse, and the storage that store consumes is charged against Dataverse database capacity. It surfaces in the Power Platform admin center as extra files, under names you did not create.

This matters because it is the one cost in the architecture that arrives somewhere nobody is watching.

Why this surprises people

The mental model for "export my ERP data to a lake" was set by the services Fabric link replaced. Export to Data Lake and Azure Synapse Link both write into an ADLS Gen2 account you provision, inside a subscription you already track, next to a cost centre that already exists. The bill arrives in Azure, where somebody is looking at it.

Link to Fabric inverts that. There is no storage account to create, which is one of its genuine advantages, and the consequence is that the storage lands inside the Power Platform tenant instead. Capacity there is bought differently, monitored by different people, and alerted on by a system the Azure cost owner may not receive mail from.

So the first sign is often a Dataverse capacity warning rather than a cost review, and the person who receives it has no obvious reason to connect it to a Fabric project they were not part of.

What you are actually paying for

Two things, and only one of them is negotiable.

The managed store. Dataverse keeps a Delta/Parquet copy of the linked tables. That copy is what the shortcuts point at, and it is what consumes capacity.

The tables you cannot exclude. Every non-system Dataverse table with change tracking enabled is selected automatically and cannot be removed, because Dynamics and partner applications depend on them. F&O tables you can choose. The scope is therefore partly your decision and partly not, and the part that is not still consumes capacity.

That second point is the one to plan around. "We will only sync what we need" is half true, and the half that is not true is the half you cannot see until it is syncing.

How large it actually gets

Smaller than the raw figure, and the compression is meaningful. Microsoft's own worked example puts a 500 GB sync at roughly a 100 GB increase in Dataverse storage, which is a five to eight times reduction from Delta/Parquet encoding.

That is a useful planning ratio and a poor substitute for measuring your own estate, because compression depends on the shape of the data. Wide tables of repeated categorical values compress hard. Tables dominated by high-cardinality identifiers and free text do not.

There is also a scale ceiling worth knowing before you plan: environments with more than about two thousand active Dataverse tables are where Link to Fabric starts to fail rather than merely slow down. If your environment is near that, establish it before the project rather than during it.

Where to look

Power Platform admin center, capacity. The linked store appears as additional files against the environment. The naming carries environment, profile and workspace segments, so it is identifiable once you know to look, and cryptic if you do not.

Before you link, take a baseline. Record current Dataverse database and file capacity. Without a before, the after is an argument rather than a measurement.

After the initial sync, wait. The first conversion to Delta/Parquet can take up to an hour and longer for large tables, and steady-state refresh runs on a similar cycle. Reading capacity mid-sync will tell you something that is not the steady state.

Deciding whether it is the right bill

None of this is an argument against Link to Fabric. Not managing a storage account is a real operational saving, and shortcuts rather than copies is the cleaner architecture for most estates already committed to Fabric.

It is an argument for knowing which budget the cost lands in before you commit, because the alternative path exists precisely for the cases where it should land elsewhere. If you need the data in your own storage account, in your own subscription, or in non-Microsoft tools, Azure Synapse Link for Dataverse writes Delta-Parquet into ADLS Gen2 that you control, with the cost where you expect it. That is a legitimate reason to choose it, and cost ownership is a legitimate input to the decision.

The failure is not choosing either one. It is choosing Link to Fabric for its architecture and discovering its billing model six weeks later, during a capacity alert, in a team that was not in the project.