Salesforce has two storage allowances, not one, and they are sized very differently. Both grow with your user count, but on Enterprise each user adds 20 MB of data storage and 2 GB of file storage — a hundred to one. That ratio is why the storage warning almost always turns out to be the data meter, and why advice that treats “Salesforce storage” as a single number fixes the wrong half.
The short version: on Enterprise you get 10 GB of data storage plus 20 MB per user, and 10 GB of file storage plus 2 GB per user. Records cost about 2 KB each no matter how many fields they hold. Because the file allowance per user is 100x the data allowance, most orgs run out of data storage first — and a real 122-user org we checked was at 89% data against 13% file.
The two allowances, and what actually counts against each
Data storage holds records — accounts, contacts, cases, custom objects, and most of what you think of as your CRM. File storage holds the binary content hanging off them: Files, attachments, Documents, and Salesforce CRM Content. They have separate meters, separate limits, and separate remedies. Archiving records does nothing for file storage. Moving files out does nothing for data storage.
| Data storage | File storage | |
|---|---|---|
| Base, per org | 10 GB | 10 GB |
| Enterprise | +20 MB per user | +2 GB per user |
| Unlimited / Performance | +120 MB per user | +2 GB per user |
| Professional | +20 MB per user | +612 MB per user |
| Holds | Records | Files, attachments, Documents |
| Fixed by | Archiving or deleting records | Moving file content out |
Contact Manager and Group match Professional at 612 MB of file storage per user, and orgs on those editions with fewer than 10 users get 1 GB per user instead. Developer and Personal editions are far smaller and are not the subject of this post. Every one of these numbers is a published default: add-ons and licence mix change the real figure, so Setup > Storage Usage is the only authority for your org.
Which meter actually runs out first
Almost always the data one, and the arithmetic shows why. Take a 122-user Unlimited org. Data storage comes to 10 GB plus 122 × 120 MB, about 24 GB. File storage comes to 10 GB plus 122 × 2 GB, about 256 GB. Same org, same day, and one allowance is more than ten times the other.
We checked a real org with exactly that shape. It was sitting at 89% of data storage and 13% of file storage. Nothing unusual had happened to it — that is simply what the allocation ratio produces once an org has a few years of records behind it. Which is why the first question is never “how do we reduce storage”, it is “which meter is the warning about”.
Check before you plan anything
Setup > Storage Usage gives your real allocation and usage for both meters, and it accounts for add-ons and licence mix that no published table can. Do this first. A file-offload project on an org whose data meter is the problem is months of work that moves nothing.
Why adding fields does not use storage, and deleting them does not reclaim it
Most records count as roughly 2 KB each, whether they hold two populated fields or two hundred. Person Accounts are about 4 KB and Campaigns about 8 KB. The practical consequence surprises people: a field-cleanup project will not move your data storage number at all. It is worth doing for other reasons — usability, page load, admin sanity, our own field cleanup work exists precisely because of them — but if the goal is storage, record volume is the only lever that matters.
Salesforce data archiving: move records, don't delete them
Archiving means moving records that are no longer operationally active out of the standard allowance while keeping them retrievable. The usual options:
- •Big Objects — Native, holds huge volumes, and does not count against standard data storage. The trade-off is querying: async SOQL and a restricted index model, so it suits write-once history rather than anything you report on interactively.
- •External archive with a connector — Records move to a data store you control and stay accessible through a Salesforce interface. Costs money, but keeps the audit trail intact.
- •Export and delete — The cheapest and the most dangerous. Fine for genuinely dead data with a retention decision behind it. Not fine as a quarterly panic response to a storage warning.
The objection that stalls most archiving projects is not technical. It is that nobody will sign off on losing history. Archiving answers that; deletion does not. Decide the retention rule first and the tooling question gets much easier.
Fixing file storage: stop storing the bytes in Salesforce
File storage has a generous per-user allowance, so it usually is not the binding constraint. The exception is orgs that attach contracts, signed forms, site photos, or anything scanned at volume — where file growth is driven by process rather than headcount, the 2 GB per user stops keeping pace and the file meter becomes the problem.
The structural fix is to keep the file content in storage you already pay for — SharePoint, Google Drive, Box, Dropbox, or S3 — and keep only a reference on the Salesforce record. Users still open the document from the record; the bytes simply are not sitting in your Salesforce allocation. Per-GB, general-purpose cloud storage costs a fraction of Salesforce's rate, and it does not renegotiate itself upward at contract renewal.
When buying more storage is the right answer
If you are 2 GB over and flat, buy the block. An integration project to save a few hundred dollars a year is a bad trade, and we will tell you so. Offloading wins when file volume is growing steadily, because the gap compounds — and it wins on architecture when files need to be reachable by teams who do not have Salesforce licences.
Where DocFynd fits
DocFynd is our Salesforce-native document management app. It connects records to external cloud storage — Google Drive, SharePoint, Box, Dropbox, or S3 — so uploads land in the store you already own, organised by folder rules you define, while the record keeps a clean link. Admins configure it once; end users upload from the record page without thinking about where anything lives.
It solves file storage. It does not solve data storage — if your problem is 40 million case records, DocFynd is the wrong tool and an archiving approach is the right one. Check Storage Usage in Setup before you decide which conversation you are having, because the two numbers point at completely different projects.
Not sure which storage meter is your problem?
Send us your Setup > Storage Usage numbers and we will tell you whether you need archiving, a file offload, or simply to buy a block — including when the answer is that you do not need us.
Four fields, no call required. We reply within one business day.
Frequently asked questions
What are the Salesforce storage limits?
There are two separate allowances, and both scale with your user count. Data storage starts at 10 GB per org, plus 20 MB per user on Enterprise and Professional, or 120 MB per user on Unlimited and Performance. File storage also starts at 10 GB per org, plus 2 GB per user on Enterprise, Performance and Unlimited, or 612 MB per user on Professional, Contact Manager and Group. Always confirm against Setup, Storage Usage, because add-ons and licence mix change the real number.
Does Salesforce file storage increase per user?
Yes. Enterprise, Performance and Unlimited are allocated 2 GB of file storage per standard user licence on top of the 10 GB org base. Professional, Contact Manager and Group get 612 MB per user, and orgs on those editions with fewer than 10 users get 1 GB per user instead. The practical consequence is that file storage is allocated roughly 100 times more generously per user than data storage on Enterprise, which is why data storage is usually the allowance that runs out first.
How is Salesforce data storage calculated per record?
Most records count as roughly 2 KB each regardless of how many fields they hold, so a record with 200 populated fields consumes the same as one with two. Person Accounts are about 4 KB and Campaigns about 8 KB. This is why adding custom fields does not meaningfully increase data storage, and why deleting fields does not reclaim it. Record volume is what moves the number.
What is the difference between data storage and file storage in Salesforce?
Data storage holds records: accounts, contacts, cases, custom objects. File storage holds the binary content attached to them: Files, attachments, Documents, and the content of Salesforce CRM Content. They have separate allowances and separate remedies. Archiving records frees data storage and does nothing for file storage. Moving files to external storage frees file storage and does nothing for data storage. Solving the wrong one is the most common mistake here.
How do I reduce Salesforce storage without deleting anything?
For data storage, archive records to an external store or to Big Objects, which keeps them queryable while removing them from the standard allowance. For file storage, move file content to storage you already pay for elsewhere and keep a reference in Salesforce, so users still open the file from the record. Neither approach requires deleting business history, which is usually the objection that stalls a storage project.
Is it cheaper to buy more Salesforce storage or offload it?
It depends which allowance you are short of and by how much. Salesforce sells additional storage in blocks at a list price that is high relative to general-purpose cloud storage, so a small, flat overage is often cheapest to simply buy. Sustained growth is where archiving or offloading wins, because the external cost per GB is a fraction of the Salesforce rate and does not grow with your Salesforce contract. Check which meter is near its limit first — the two problems have completely different fixes.