Salesforce Storage Limits Explained: Data Storage and File Storage
Salesforce sells storage above your included allotment in fixed-size blocks, and the per-GB price is steep enough that overages add up quickly. Most admins only discover they're over the limit when an in-app storage warning appears or a Salesforce account rep flags it. This guide explains how the two storage limits are calculated, what counts against each, and where to look in your org to see the current numbers.
Why Salesforce has two storage limits
Salesforce splits storage into two independent buckets, each with its own allotment and its own overage pricing:
- Data storage covers records — rows in standard and custom objects. The bytes Salesforce charges for are not the actual field bytes; they're a fixed per-record allowance.
- File storage covers binary blobs — uploaded files, attachments, notes, knowledge article content.
The two buckets are billed separately, and you can max out one while the other has room to spare. A high-volume sales org with millions of Leads and Opportunities tends to push data storage; a service org with email-to-case and case attachments tends to push file storage. The mitigation strategies are different for each — there's no single fix.
How data storage is calculated
Most standard and custom records count as approximately 2 KB per record, regardless of how many fields the record has or how much text those fields contain. Account, Contact, Lead, Opportunity, Case, Campaign, custom objects — all use the same 2 KB convention for storage accounting.
A few categories behave differently:
Person Accountrecords count as 2 records (Account + Contact), so 4 KB each.Campaignrecords count higher (historically 8 KB) because of their relationship overhead.Articleversions andEmailMessagerecords have their own accounting —EmailMessagebody content is typically counted against file storage, not data.Big Objectsand archive-style storage products (Salesforce Archive, Field Audit Trail data past the standard window) don't count against data storage.Activity Historyrows count against data storage.Login History, debug logs, and most platform telemetry don't.
Because the cost is per record rather than per byte, the way to reduce data storage is to delete or archive records, not to trim fields. Verify the exact per-object cost for your edition in Salesforce's Storage Allocations help topic — Salesforce has changed these values over time.
How file storage is calculated
File storage is sized by actual binary content, not a flat per-object rate. What counts:
ContentVersion— the storage object behind Salesforce Files. TheContentSizeof every version counts, including superseded versions, not just the latest. Uploading a new revision of an existing file roughly doubles its storage cost until you delete old versions.Attachment— the legacy attachment object. Each row'sBodyLengthcounts.Document— the legacy Documents tab object.ContentNote— modern enhanced notes. They use file storage, not data storage, even though they're text.- Knowledge article body content and attachments.
- Email message bodies and attachments captured by Email-to-Case or Enhanced Email.
Files attached to multiple records via ContentDocumentLink only count once — the underlying ContentDocument is what's stored. Deleting the link doesn't free storage; you have to delete the ContentDocument itself (and empty the Recycle Bin).
Edition-by-edition base limits
The numbers below are approximate and change over time. Use your org's Storage Usage page as the authoritative source — these are starting points for planning.
| Edition | Base data storage (per org) | Base file storage (per org) | Per-user file allotment |
|---|---|---|---|
| Essentials / Professional | ~1 GB | ~10 GB | Approx. 2 GB/user (varies) |
| Enterprise | ~10 GB | ~10 GB | Approx. 2 GB/user |
| Unlimited | ~10 GB | ~10 GB | Approx. 2 GB/user |
Most editions also add a small per-user data storage increment (historically around 20 MB per user license), and Sandboxes have their own allocations that are separate from production. Add-on storage purchased from Salesforce stacks on top of the base. Always verify the exact figures in your org — the Storage Usage page shows the limit Salesforce is actually enforcing for you.
How to check your storage
Navigate to Setup → Data → Storage Usage in either Classic or Lightning. You'll see three sections:
- Storage summary — total data storage used vs allowed, and total file storage used vs allowed. The percentage column is the one to watch.
- Current data storage usage — record counts by object, sorted by storage consumed. This is where you discover that
EmailMessageor a customAuditLog__cobject is responsible for most of your data storage. - Current file storage usage — file storage by largest file type and by user. Less granular than the data view, but enough to find the heavy uploaders.
Storage Usage is calculated periodically, not in real time — recently deleted records can take hours to drop off, and recently created ones can take just as long to appear.
What counts as "files" vs "data"
The distinction trips people up because some objects feel like records but are stored as files (and vice versa). Quick reference:
- Tasks and Events — data storage. Each row counts as ~2 KB.
- Legacy Notes (
Note) — historically counted as data storage with a fixed per-record allowance. - Enhanced Notes (
ContentNote) — file storage. Text is stored as aContentVersion. - Attachments (legacy) — file storage, sized by
BodyLength. - Files (modern,
ContentVersion) — file storage, all versions counted. - Knowledge articles — file storage for body content and attached files.
- EmailMessage — body counts as file storage; the
EmailMessagerecord itself counts toward data storage. - Big Objects — neither bucket. They're sold separately and don't appear on Storage Usage.
What happens when you hit the limit
Salesforce's enforcement is mostly soft. The behavior you should expect:
- Warning banners appear in Setup and on user-facing pages once you cross typical thresholds (often around 80%, 90%, 100%).
- Sales / account contact — your Salesforce account team will reach out about purchasing additional storage. This is the most common way orgs discover they're over.
- Record creation is generally not blocked outright. Some Salesforce documentation has historically described hard blocks past a certain percentage, but in practice most orgs continue to function while over the limit until the next contract negotiation.
- File uploads can begin to fail when file storage is exhausted, particularly on Free / Developer Edition orgs. Production orgs typically get warnings rather than hard failures.
- Overage billing — the real consequence. Salesforce sells incremental storage in fixed blocks, with file storage and data storage priced separately. Per-GB pricing is high relative to commodity object storage.
Don't rely on Salesforce hard-blocking writes to enforce a cap — by the time you'd notice the block, you've already been over for a while and the renewal conversation is going to include an overage line item.
How to reduce storage
Once you know which bucket is full and which objects are responsible, there are four strategies, in increasing order of complexity:
- Archive — move old files to external storage (typically S3) with a Salesforce tracking record so users can still find them.
- Delete — remove records and files you can confidently identify as junk (duplicate uploads, test data, files attached to deleted records).
- Deduplicate — find files uploaded multiple times across records and consolidate them.
- Restructure — for data storage, split high-volume custom objects into Big Objects or external systems; for file storage, tier files by access pattern.
For a deeper walkthrough of each strategy with trade-offs, see Salesforce Storage Costs: What You're Paying and How to Reduce It.