Dataverse storage types explained

Dataverse storage isn't one number; it's three separate categories — Database, File, and Log — each metered and billed separately. Understanding what goes where and how to control growth is essential for any production deployment, especially as data accumulates over years.

The three categories.

• Database — relational data: standard tables, columns, indexes, plug-in step storage.
• File — large binary content: attachments, image columns, file columns.
• Log — audit logs, plug-in trace logs.

Each has its own entitlement based on the tenant's licences.

What counts as Database.

• All row data.
• Indexes.
• Plug-in steps and assemblies.
• Some metadata.

For text content stored in standard columns, it counts as Database. Standard relational data.

What counts as File.

• Attachments (file binary content).
• Image columns.
• File columns (a column type that stores files directly).
• Some other binary storage.

File storage is typically the fastest-growing category for any production environment with attachments. Users upload PDFs, photos, documents — they accumulate quickly.

What counts as Log.

• Audit history records — who changed what when.
• Plug-in trace logs.

Log can grow rapidly if audit is broadly enabled.

Entitlements.

• Each tenant gets some baseline allocation.
• More licences (more Dynamics 365 base licences) = more allocation.
• Per-licence allocation: typically GB per licence per type.
• Tenant total = sum of per-licence allocations + any add-on purchases.

The exact numbers shift; check current Microsoft documentation. Roughly:

• ~250 MB Database per licence (for Dynamics 365 base licences).
• ~2 GB File per licence.
• ~2 GB Log per licence.

Plus a baseline tenant allocation. Mid-size deployments may have hundreds of GB available; large enterprises terabytes.

Capacity reports. In Power Platform admin centre:

• Capacity page shows current usage per category.
• Per-environment breakdown.
• Trend over time.

Watch the trend; capacity should grow predictably, not explosively.

What happens at exceeding.

• Approaching limit (90%+) — alerts to admins.
• Exceeded — Microsoft may restrict new data creation; eventual operations affected.
• Persistent overage — purchase additional capacity or reduce usage.

The grace period varies; don't rely on tolerance.

Add-on capacity. Microsoft sells capacity packs:

• Database — per GB per month.
• File — per GB per month, cheaper than Database.
• Log — per GB per month.

File is cheapest per GB; encourage moving large content to File-typed columns rather than text columns.

Controlling Database growth.

• Bulk delete old records — old leads, completed cases, expired campaigns.
• Archive to external store — Synapse Link to ADLS for long-term retention.
• Index efficiency — remove unused indexes.
• Trim plug-in steps — old, unused plug-ins still count.

Controlling File growth.

• Move attachments to OneDrive / SharePoint — link instead of embed.
• Compress images before upload.
• File retention policies — auto-delete old attachments.
• Audit attachment usage — large files rarely accessed are candidates for archive.

For a mature tenant, File can be the dominant cost; aggressive management pays back.

Controlling Log growth.

• Selective audit — only audit tables that need it.
• Audit retention — auto-delete logs older than N months.
• Audit categorisation — fewer events per table reduces log volume.

For organisations not in regulated industries, broad audit is often overkill.

Storage tier comparison.

| Type | Use | Cost / GB | Growth rate | |---|---|---|---| | Database | Standard data | Highest | Moderate | | File | Binary content | Moderate | Fast | | Log | Audit / traces | Cheapest | Variable |

For optimisation, focus on Database (most expensive), then File (highest growth), then Log.

Auditing storage. Periodically:

• Top tables by row count.
• Top columns by storage.
• Top file attachments by size.
• Audit log volume.

These reveal where capacity is going.

Strategic moves.

• Long-term data → external lake. Synapse Link or Fabric Link replicates to lake; Dataverse retains operational data only.
• Attachments → SharePoint. Link-based; SharePoint storage often cheaper and bundled with M365.
• Old data → archived. Use bulk delete after archive confirmed.
• Capacity planning per project — new initiatives estimate storage impact.

Common pitfalls.

• Capacity surprise. Bills exceed budget; nobody was watching.
• Audit on everything. Log grows fast; auditor doesn't need it all.
• Attachments unmanaged. File usage balloons.
• No archival strategy. Old data accumulates forever.
• Capacity reports ignored. Trend not monitored; preventable issues become crises.

Operational rhythm.

• Monthly — capacity review.
• Quarterly — audit retention and cleanup.
• Annually — strategic review of growth trajectory and add-on needs.

Strategic positioning. Storage isn't free; ignoring it leads to surprise costs and operational restrictions. Active management — categorisation, retention policies, archival strategy — keeps costs predictable and Dataverse performant. The teams that get this right have boring storage stories; the teams that don't have surprise bills and emergency cleanups. The cost of attention is small; the cost of neglect compounds.