Bring-your-own-storage patterns for Dataverse

"Bring your own storage" gets asked for in Dataverse projects for three unrelated reasons that happen to share a phrase. Someone wants the storage bill to go down. Someone wants the data to sit in an Azure subscription they control. Someone in compliance wants to hold the encryption keys. Dataverse does not offer a single switch that moves its database into your storage account, and anyone promising that is describing something else. What it offers is a set of specific mechanisms, each answering one of those three needs, and it pays to match the mechanism to the need before anyone buys a storage account.

What Dataverse will not do

Dataverse's transactional database is Microsoft-managed. You cannot point it at your own Azure SQL or storage account, and you cannot run it on-premises. Its capacity model, described in Dataverse storage types explained, splits usage into Database, File, and Log, and all three are billed as Dataverse capacity regardless of what you would prefer. The patterns below work around the edges of that model; none of them replace it.

Need 1: control of encryption keys

Customer-managed keys (CMK). Dataverse environments can be encrypted with a key you hold in Azure Key Vault rather than a Microsoft-managed key. Microsoft still stores the data; you control the key, can rotate it, and can revoke it, which renders the environment inaccessible until access is restored. This is the compliance answer for organisations whose policy requires key custody. It applies to Managed Environments, needs an enterprise policy in Azure, and carries operational responsibility: lose the key, lose the environment. It does not reduce cost or move data.

CMK is not BYOS in the literal sense, but it is often what the compliance requirement behind a BYOS request is actually asking for. Confirm that before going further. See Dynamics 365 data protection and compliance.

Need 2: data in a subscription you control

Synapse Link to your own data lake. The closest thing to true bring-your-own-storage. Dataverse continuously writes a copy of selected tables to an ADLS Gen2 account in your subscription, in your region, under your access controls. It is a copy for analytics and integration, not the operational database, and Dataverse keeps running from its own storage. But it satisfies the requirement that a full, current copy of the data lives in storage you own and can retain, secure, and hand to any tool you like. See Azure Synapse Link for Dataverse.

The Fabric variant, Link to Fabric, keeps the data in Dataverse-managed storage and exposes it through OneLake without a copy. It is simpler but does not put anything in your subscription; if that was the point, use Synapse Link.

Long-term retention. Dataverse's long-term data retention feature moves inactive rows to a cheaper Microsoft-managed tier inside Dataverse. It is about cost, not custody, and belongs under the next heading.

Need 3: lower storage cost

File storage is where Dataverse bills hurt: attachments, images, and documents accumulate and are charged as File capacity. The patterns that offload them:

SharePoint document management. The standard integration stores documents in SharePoint document libraries linked to Dataverse records, using Microsoft 365 storage rather than Dataverse File capacity. It is first-party, mature, and the default answer for documents on accounts, cases, and opportunities. See SharePoint document management for Dynamics 365. It does not cover note attachments or email attachments automatically.

Attachment offload to Azure Blob or SharePoint. Note and email attachments can be moved out of Dataverse to Azure Blob storage or SharePoint by an attachment management solution, of which Microsoft has published one and several ISVs sell others, or by a custom plug-in that intercepts the attachment on create and stores a link. This is the true BYOS for files: the bytes live in your storage account, Dataverse holds a pointer. The catch is that everything that expects the attachment to be in Dataverse (exports, some mobile clients, some reports) needs to understand the pointer.

Long-term data retention for row data: policies move old cases, activities, and custom-table rows into a retained store that is queryable but cheaper. Rows come back read-only through a separate path. It is the right tool for compliance retention of closed records that nobody edits.

Archiving to your own store. Export old rows through Synapse Link or a scheduled pipeline into your lake, then bulk delete them from Dataverse. Cheapest, fully in your control, and the rows are gone from the application. Suitable when the business agrees that old data lives in reports, not in forms.

Choosing

Key custody: CMK. A copy in your subscription: Synapse Link. Documents: SharePoint integration. Attachments driving File capacity: an offload solution to Blob or SharePoint. Old rows driving Database capacity: long-term retention if they must stay queryable in place, archive-and-delete if they need not.

What breaks in practice

CMK operations that were not rehearsed, so a key rotation locks people out. Synapse Link storage accounts created without lifecycle policies, so the lake costs more than the Dataverse capacity it was meant to offset. Attachment offload solutions that break a downstream integration expecting real attachments. Archive-and-delete run without confirming that a report somewhere reads those rows.

Stability verdict

Every mechanism here is supported and stable. The instability is expectation: a BYOS request usually arrives as one sentence and needs three mechanisms to satisfy properly, or one mechanism once the actual requirement is pinned down. Pin it down first.