I enabled Fabric link for the annotation table (Notes) and despite it only being 3 GB, a table called annotation-analytics was created in the database storage of 180 GB. This seems a bit expensive and I would generally recommend against adding annotation to Fabric Link.

Working with a customer yesterday where I need to get work with some specific N:N tables in Fabric and hence enabled the Fabric Link as that is sometimes required for some tables that don’t show up in the normal “add shortcut” to Dataverse from Fabric. Seems like after they have been enabled for Fabric export to any datalake, they are enabled in shortcuts too.

However I also thought that I later might have use of the annotation table (display name is Notes for those who are unaware) so I enabled that too. This was last thursday. This monday I got complaints that the dataverse db storage in our tenant had gone through the roof with several 100 GB. Hence I started investigating what had happend.

To do this, you can check the storage consumption in the Power Platform Admin Center under Licensing -> Dataverse. To my surprise I found that there was a new table at the top of the consumption and that it was called “annotation-analytics”. Now this might not seem strange but it is. Dataverse has a somewhat hidden feature called the “managed datalake”, this is a feature where tables in the database are mirrored into the file storage as a datalake in parquet-delta format. When you enable the Fabric link/short cut from Fabric, this is actually what you see. It will not actually copy the data to Fabric but rather link to it. Similar to mounting a harddrive on the local network. For dataverse to be able to do this, the change tracking feature has to be switched on for the specific table. And when you enable a table for Fabric Link it will cause the table to be replicated to the file storage. When you look at the consumption in the file storage you will hence see many tables called something like “-analytics” for instance “account-analytics”. This is just normal behaviour for how dataverse enables synchronization of the dataverse internal SQL database to the managed datalake.

This is where things become stranger, as I would not be surprised to find “annotation-analytics” in the file storage, however, it shows up in the database storage, not the file storage. Now, why is this a problem? Well, database storage is charged at list price $40/GB and month while file storage is $2/GB and month and there is a lot more file storage included in the normal user licenses. Hence the 180 GB of storage that showed up would result in an additional 180x$40 = $7200/month in cost, just for having the annotation enabled in Fabric link… not saying that it is impossible to find use cases where there is justification for this cost, but it is a bit on the harder side to identify these.

My next option was to try to remove the annotation from the tables being synchronized in the Fabric Link. That was not possible however due to there being a small asterisk next to the table name saying that it cannot be removed due to being used by something somewhere (unclear exactly what and where). Fortunatley, I hadn’t implemented anything using this in Fabric yet, so I could just remove the entire Fabric Link and recreate it without adding annotation. This might not always be the case and that could cause significant refactoring work. Hence I would warn against adding annotation to the Fabric link. According to the Microsoft support agent this is documented behaviour for the Fabric Link for this table. However, setting Fabric Link for the annotation table of 3 GB and it using 180 GB of db storage doesn’t seem like flawless feature implementation from my perspective, even if it isn’t a bug.

As for a general recommendation, I suggest only selecting the tables that you actually will use in Fabric and not tables that might be useful in the future. It is very easy to add new tables but complex to remove them.