This series covers the full storage picture in Microsoft 365: how it works, what's consuming it, how to manage it, and how to build a governance framework around it before it becomes a crisis.
This first post covers the fundamentals — how the storage model works, what counts toward your quota, and why version history deserves more attention than it often gets.
Series: Managing Storage in Microsoft 365 — Part 1 of 4. Part 2 covers archiving and backup.
Storage in Microsoft 365 is one of those topics that organisations rarely think about until capacity warnings start appearing. By then, the problem has been quietly growing for years — driven less by intentional file storage and more by automatically generated versions created during normal collaboration.
How SharePoint and OneDrive Storage Works
Microsoft 365 storage for SharePoint and OneDrive operates on two separate models — a common source of confusion.
SharePoint — Tenant-Wide Pooled Storage
SharePoint Online storage is pooled at the tenant level, with all site collections drawing from the same shared pool. Most tenants receive a base allocation of 1 TB plus additional pooled storage based on eligible licences — typically 10 GB per licensed user, though not every licence type contributes equally and some licences do not contribute storage entitlements at all.
So a typical 100-seat Microsoft 365 Business Premium tenant gets approximately 1 TB + 1 TB = 2 TB of pooled SharePoint storage. A 500-seat enterprise tenant gets approximately 1 TB + 5 TB = 6 TB. This pool is shared across all SharePoint sites including Team sites, communication sites, and channel sites. No individual SharePoint site can exceed 25 TB.
OneDrive — Per-User Separate Allocation
OneDrive for Business storage is allocated per user and managed separately from the SharePoint tenant pool. Each user's licence determines their OneDrive quota — the default is 1 TB per user for most Microsoft 365 plans, with enterprise plans eligible for expansion to 5 TB or beyond on request.
It is worth noting that OneDrive for Business is technically built on SharePoint Online infrastructure and administered through SharePoint services, which is why OneDrive accounts appear in SharePoint admin reporting. However, OneDrive user quotas are allocated separately from pooled SharePoint tenant storage — they are managed as separate quota allocations for administrative purposes.
What Counts Toward Each Quota
What counts toward the SharePoint pool quota:
- Files stored in SharePoint document libraries
- All versions of every file in SharePoint
- Teams channel files (stored in SharePoint)
- Microsoft Loop content and workspaces (storage location depends on the Loop component type and backing service — this is an evolving area)
- Microsoft 365 Group content stored in SharePoint
- Both first-stage and second-stage Recycle Bin content — deleted content remains in the recycle bins for up to 93 days unless permanently removed earlier
What counts toward OneDrive per-user quota:
- Files stored in a user's OneDrive
- All versions of every file in OneDrive
- Files shared in Teams chats (stored in the sender's OneDrive)
What doesn't count toward either:
- Exchange Online mailboxes (separate quota)
- Teams chat messages themselves (separate storage)
Modern collaboration workloads as hidden storage consumers: Beyond traditional file storage, modern collaboration tooling increasingly stores content in SharePoint-backed services. Teams meeting recordings stored in SharePoint or OneDrive, Stream videos, Whiteboard sessions, and Viva Engage file attachments all contribute to storage consumption — often in ways that are less visible than documents in a library. Storage growth in mature Microsoft 365 tenants frequently comes from collaboration tooling rather than traditional file shares.
Checking Your Storage Usage
The SharePoint Admin Centre already provides site storage reporting — the Active sites page shows storage used per site and can be sorted to surface your largest consumers. This is available without any additional licences.
For a more detailed picture, SharePoint Advanced Management (SAM) adds deeper lifecycle, governance, and management capabilities that can help identify inactive or high-risk sites, with richer analytics on top of the standard admin centre reporting. SAM is a separate paid add-on — the standard admin centre reporting is available to all tenants.
In PowerShell, the storage picture per site is available via:
Connect-PnPOnline -Url "https://yourtenant-admin.sharepoint.com" -Interactive -ClientId "your-client-id"
Get-PnPTenantSite | Select-Object Url, StorageUsageCurrent, StorageQuota | Sort-Object StorageUsageCurrent -DescendingStorageUsageCurrent is in MB. Sites at the top of the list are your biggest consumers and the first place to investigate. The 25 TB figure showing in StorageQuota is the platform maximum, not an allocated quota. Setting meaningful quotas on high-growth sites is the governance action worth taking.
For a tenant-level overview — verify property names in your environment before using in production:
$sites = Get-PnPTenantSite
$totalMB = ($sites | Measure-Object -Property StorageUsageCurrent -Sum).Sum
$totalGB = [math]::Round($totalMB / 1024, 2)
Write-Host "Total storage used across all sites: $totalGB GB"Version History — Why Storage Grows Faster Than You Expect
Version history is enabled by default on every SharePoint document library and OneDrive. Every time a document is saved, frequent AutoSave activity and collaborative editing can significantly increase version creation frequency. For an actively edited Word document this can mean dozens of versions per day.
Multiply that by hundreds of documents across hundreds of sites, and version storage becomes one of the largest contributors to your storage consumption — often accounting for more than the actual document content itself.
Version Limits
Historically, many SharePoint document libraries defaulted to retaining 500 major versions per file. Microsoft is increasingly moving toward automatic version history management and Intelligent Versioning, meaning many tenants will use adaptive retention behaviour rather than fixed version counts. However, older libraries configured before this shift may still operate on fixed version limits.
The storage impact depends on file size. A 10 MB PowerPoint with hundreds of versions could be consuming several gigabytes of storage for a single file. Multiplied across a busy site the numbers become significant quickly.
Intelligent Versioning
Intelligent Versioning provides a more efficient approach to managing file versions, using adaptive trimming logic to reduce redundant versions while preserving recent and meaningful recovery points. Microsoft describes this as retaining more granular recent history while reducing older intermediate versions — the exact internal algorithm is not fully documented as a stable public specification, but the intent is to remove low-value intermediate saves while keeping the history that matters.
Enabling Intelligent Versioning can be done at the tenant level in the SharePoint Admin Centre under Settings → Version history limits, or per site via PowerShell. Availability and rollout status may vary depending on tenant configuration and Microsoft service rollout timelines — if you don't see the option, check whether it has reached your tenant yet.
Set-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/yoursite" -EnableAutoExpirationVersionTrim $trueImportant — tenant settings apply to new libraries only: Tenant-level version history defaults generally apply to newly created document libraries and new OneDrive accounts. Existing libraries usually require explicit updates — they will not automatically inherit tenant-level changes.
Retention policies and version trimming: Retention policies and retention labels can significantly reduce or block version trimming because retained versions may need to be preserved for compliance purposes. For organisations with active retention policies, Intelligent Versioning may have limited effect on the content covered by those policies. This creates an important planning consideration: blanket retention policies applied too broadly not only impose compliance overhead but also prevent version trimming across all covered content. The storage cost of that decision compounds year on year.
Content not covered by retention policies is the primary target for version trimming — knowing which content is covered and which isn't is a prerequisite for effective storage management. The compliance layer is covered in detail in Part 3 of this series.
Manual Version Trimming with PnP PowerShell
For existing libraries with large version histories, manual trimming via PnP PowerShell gives you direct control.
Warning: Version deletion is irreversible. Always test using a reporting or dry-run approach before deleting versions in production. On very large libraries, Get-PnPFileVersion may perform slowly — consider batching operations and adding throttling controls for large-scale cleanup. The first script will output exactly what you have in a given library.
Script 1 — Version report (run this before deleting)
Connect-PnPOnline -Url "https://tenantName.sharepoint.com/sites/siteName" -Interactive -ClientId ""
# Get all files in a library and their version counts — DRY RUN, no deletion
$items = Get-PnPListItem -List "SitePages" -Fields "FileLeafRef", "FileRef", "FSObjType"
foreach ($item in $items) {
# Skip folders (FSObjType = 1), only process files (FSObjType = 0)
if ($item["FSObjType"] -eq 1) { continue }
$versions = Get-PnPFileVersion -Url $item["FileRef"]
Write-Host "$($item["FileLeafRef"]) has $($versions.Count) versions"
}Script 2 — Delete versions
Connect-PnPOnline -Url "https://tenantName.sharepoint.com/sites/siteName" -Interactive -ClientId ""
$items = Get-PnPListItem -List "SitePages" -Fields "FileLeafRef", "FileRef", "FSObjType"
foreach ($item in $items) {
# Skip folders
if ($item["FSObjType"] -eq 1) { continue }
$versions = Get-PnPFileVersion -Url $item["FileRef"]
if ($versions.Count -gt 50) {
Write-Host "$($item["FileLeafRef"]) has $($versions.Count) versions"
$toDelete = $versions | Sort-Object Created -Descending | Select-Object -Skip 50
foreach ($version in $toDelete) {
Remove-PnPFileVersion -Url $item["FileRef"] -Identity $version.Id -Force
}
}
}Adjust the 50 threshold to whatever makes sense for your organisation. A more complete version trimming script — with tenant-wide scope, reporting output, and dry-run mode — is available on the scripts page.
Storage Quotas and Site-Level Management
By default, SharePoint sites draw from the tenant pool without a site-level quota. This means a rapidly growing site can consume a disproportionate share of tenant storage without any automatic check.
Setting site-level quotas gives you predictability and prevents any single site from consuming storage without governance oversight:
# Set a 100 GB quota on a specific site
Set-PnPTenantSite -Url "https://yourtenant.sharepoint.com/sites/yoursite" -StorageQuota 102400 -StorageQuotaWarningLevel 92160StorageQuota is in MB. Warning thresholds generate quota warnings and administrative notifications when reached — a useful early signal before a site hits its limit. Excessively restrictive quotas can create operational friction, so quotas work best as governance controls for high-growth or high-risk sites rather than universal limits applied to every site.
Storage Economics
When your organisation exceeds its SharePoint storage quota, there are now two ways to handle the overage:
- Prepaid storage add-ons — purchasing additional storage capacity upfront in blocks. Requires predicting how much you'll need, which often leads to over-purchasing.
- Pay-as-you-go (PAYG) — Microsoft has introduced a PAYG billing model for SharePoint storage that removes the need to buy storage blocks upfront. You pay only for what you actually use, billed on a per-GB per month basis. To enable it: Microsoft 365 Admin Center → Billing → Pay-as-you-go → create or link a billing policy → select Microsoft 365 SharePoint Storage. Current pricing is available at the Microsoft 365 pricing page.
PAYG is a useful safety net — it removes the friction of having to purchase storage add-ons before you run out. However, the per-GB cost is the same whether you use prepaid or PAYG. Reducing unnecessary version growth and archiving inactive content remains more cost-effective than paying for ongoing overconsumption regardless of billing model — proactive version management eliminates overage costs rather than simply making them more convenient to pay.
The economics of version management, archiving, and storage expansion are covered in more detail in Part 2 (archiving and backup) and Part 4 (governance and cost management) of this series.
Where to Start
If you haven't reviewed your storage posture recently:
- Check current tenant storage usage in the SharePoint Admin Centre — are you above 70% of your quota?
- Run the PnP PowerShell storage report to identify your top 10 largest sites
- Check whether Intelligent Versioning is enabled at the tenant level — if not, enable it for new libraries at minimum
- Identify your highest-activity document libraries and check version counts on large files
- Consider setting storage quotas on your largest sites as a governance baseline
- Review whether Teams recordings, Stream content, and Whiteboard sessions are being managed — these are often overlooked storage consumers
Part 2 of this series covers Microsoft 365 Archive, SharePoint site archiving, and Microsoft 365 Backup — what each does, how they differ, and when to use which.