--- title: "Where does the storage bill land for Link to Microsoft Fabric?" canonical_url: "https://cognilium.ai/blogs/fabric-link-storage-lands-on-dataverse" slug: "fabric-link-storage-lands-on-dataverse" section: "blogs" date_published: "2026-09-14" date_modified: "2026-09-14" word_count: 956 reading_time_minutes: 4 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: - "https://cognilium.ai/blogs/what-happens-when-you-unlink-fabric" - "https://cognilium.ai/blogs/dynamics-365-optimizer-write-path" - "https://cognilium.ai/blogs/odata-throughput-dynamics-365" --- # Where does the storage bill land for Link to Microsoft Fabric? Not on Azure. Fabric link storage is charged to Dataverse capacity and shows up in the Power Platform admin center, where nobody is looking. ## Key takeaways - Link to Microsoft Fabric storage is charged against Dataverse database capacity, not against an Azure storage account. - It appears in the Power Platform admin center as extra files, which is not where the Azure cost owner is looking. - Non-system Dataverse tables with change tracking are included automatically and cannot be excluded; F&O tables you can choose. - Microsoft's own example puts a 500 GB sync at roughly 100 GB of Dataverse storage, a five to eight times compression, but measure your own estate. - Environments above roughly two thousand active Dataverse tables are where Link to Fabric begins to fail rather than slow. **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. ## Frequently asked questions ### Does Azure Synapse Link bill the same way? No, and that is the main practical difference for budgeting. Synapse Link for Dataverse writes into an ADLS Gen2 storage account you provision, so the storage cost sits in your Azure subscription where you already track it. Link to Fabric has no storage account to provision, and the managed store it uses instead consumes Dataverse capacity. ### Can I reduce what Link to Fabric stores? Partly. You can choose which F&O tables are in scope. You cannot remove non-system Dataverse tables that have change tracking enabled, because Dynamics and partner apps depend on them. So the reduction available to you is real but bounded, and it is worth establishing the bounded part before you size capacity. ### How much Dataverse capacity should I plan for? Start from Microsoft's five to eight times compression as a planning ratio, apply it to the volume of the tables actually in scope, then validate against a baseline you took before linking. Treat the ratio as a starting estimate, because compression varies with data shape rather than with volume. ### What happens if I run out of Dataverse capacity? The same thing that happens for any other Dataverse capacity overage, which is a question about the environment's capacity model rather than about Fabric specifically. The relevant point here is that a Fabric link can be the cause of an overage that looks, from the admin center, like ordinary ERP growth. ### Does unlinking free the capacity? Unlinking removes the link and deletes the Fabric lakehouse along with it, which is a more destructive action than it sounds and is worth understanding separately before anyone uses it as a capacity remedy. --- Canonical HTML: https://cognilium.ai/blogs/fabric-link-storage-lands-on-dataverse