Salesforce Data Storage Limits Explained: Check Usage, Cut Costs
Salesforce data storage is the allocation your records live in. Most editions (Professional, Enterprise, Unlimited, and others) get a 10 GB base plus a per-user-license increment, usually 20 MB per license or 120 MB on Performance and Unlimited. Most records count as roughly 2 KB no matter how many fields are filled in. You can check usage under Setup > Storage Usage.
That's the short version. The rest of this post covers how the allocations add up, which records cost more than 2 KB, what happens when you run out, and ways to get usage down other than buying more.
What's the difference between data storage and file storage?
Salesforce meters two separate pools, and running out of one doesn't touch the other. Data storage holds records: Accounts, Contacts, Opportunities, Cases, Tasks, Events, email messages, custom object rows and so on. File storage holds binary content: attachments, Salesforce Files, Salesforce CRM Content, Chatter files (user photos included), the Documents tab, Knowledge file fields and Site.com assets.
Most orgs hit the data storage ceiling first. File storage allocations are much larger, and a single 5 MB PDF is easy to see and delete. A million 2 KB task records build up slowly and nobody notices until the storage alert arrives.
How is Salesforce data storage calculated by edition?
Your data storage allocation is a per-org minimum plus a per-user amount multiplied by the number of standard user licenses. File storage works the same way with bigger numbers. According to Salesforce's Data and File Storage Allocations and Salesforce Files Storage Allocations pages:
| Edition | Data storage (org) | Data per user license | File storage (org) | File per user license |
|---|---|---|---|---|
| Contact Manager, Group, Professional | 10 GB | 20 MB | 10 GB | 612 MB (1 GB if under 10 users) |
| Enterprise | 10 GB | 20 MB | 10 GB | 2 GB |
| Performance, Unlimited | 10 GB | 120 MB | 10 GB | 2 GB |
| Essentials, Starter | 10 GB | None | 1 GB | None |
| Developer | 5 MB | None | 20 MB | None |
| Personal | 20 MB | None | 20 MB | None |
Salesforce's own example: a Professional Edition org with 10 users gets 10 GB + (10 × 20 MB) = 10.2 GB of data storage. The per-user increment matters less than people expect. An Enterprise org with 200 users gets 10 GB + 4 GB = 14 GB, which is still small next to what a busy service org creates in a few years. These minimums apply to Salesforce and Salesforce Platform licenses. If you use custom user licenses, Salesforce tells you to contact them for your exact figure.
How much storage does each record use?
Most Salesforce records use about 2 KB of data storage, whatever their field count or content length. According to Salesforce's estimated record size by object article, the exceptions are:
- Person Accounts: 4 KB. Each one is an Account and a Contact joined together, so 500,000 of them use about 2 GB.
- Articles: 4 KB, and this varies with rich-text content. Images embedded in rich text fields count toward file storage, not data storage.
- Campaigns: 8 KB.
- Campaign Members: 1 KB.
So you can estimate storage by counting records: record count × 2 KB, with adjustments for the objects above. A long description field doesn't make a Case "bigger". Having more Cases does.
How do you check storage usage in Salesforce?
From Setup, enter Storage Usage in the Quick Find box and select Storage Usage. The page shows your data and file allocations, how much of each is used, storage by record type, the top users by storage and the largest files. Sort the record-type table by size. In most orgs, three or four objects (usually Tasks, EmailMessages, Cases or a logging custom object) account for most of the usage.
Storage is calculated asynchronously, so a large import or bulk delete won't show up right away. Wait before deciding whether a cleanup worked.
What happens when you exceed your storage limit?
Behavior differs between production and sandboxes. In production, Salesforce's storage overage article says the org keeps running normally up to 100%, and beyond that performance can degrade, with the exact point depending on your implementation. Salesforce's allocation page also notes that in most cases the allocation is enforced and records can't be added once it's exceeded. Don't plan on having any headroom.
Sandboxes are stricter. When either the data or file allocation goes past 100%, inserts and uploads fail with STORAGE_LIMIT_EXCEEDED. Developer sandboxes get 200 MB of data storage, Developer Pro 1 GB and Partial Copy 5 GB, and Full sandboxes match production (sandbox limits by type). If you load test data into a Developer sandbox, this is usually the first limit you hit. Our sandbox refresh interval guide covers the rest of the per-type limits.
How can you reduce Salesforce data storage usage?
There are five approaches, from cheapest to most involved:
- Delete what nobody needs. Old debug or integration log records, duplicate leads, and abandoned custom-object data from a retired process can often just go. Check that no report, automation or integration depends on them first.
- Archive cold records externally, then purge. Closed Cases from five years ago and completed Tasks may need to be kept but don't need to take up premium storage. Extract them with their related records to external storage, verify the copy, then delete them from the org. Salesforce sells its own archiving product, and there are third-party archiving and backup tools too.
- Move high-volume, append-only data into Big Objects. Big Objects don't count against data storage, and most editions get an allocation of 1 million big object records per org. The trade-off is significant: no triggers or flows, no standard reports or list views, and queries have to follow the composite index you define up front and can't change later. They suit audit trails and event history, not working data.
- Offload files. If file storage is the problem, move large or old attachments to an external document store and link to them.
- Buy more storage. Additional storage is sold as an add-on through your account executive. It's the quickest fix and the one you'll keep paying for every year, which is why the other four are worth trying first.
If you go the archive-and-purge route, Syntharil's Salesforce data archiving does it in two phases. A dry-run plan shows record counts per object. Then it extracts complete parent-to-child record families into per-team encrypted storage and, only if you enable purge, removes them from the org once the archive has been verified by read-back. Archives can be downloaded from the app. It doesn't restore records to an org or let you browse them in-app, so it fits data you need to keep but rarely need to open.
Bottom line
Storage is 10 GB plus a per-license amount, most records are 2 KB, and in most orgs a few high-volume objects use most of it. Check Storage Usage every quarter, find those objects, and decide which records need to stay in the org for day-to-day use. Delete or archive the rest, keep Big Objects for append-only history, and buy more storage only after you've done that.
FAQ
Do attachments and files count against Salesforce data storage?
No. Attachments, Salesforce Files, Salesforce CRM Content, Chatter files, and Documents count against file storage, which is a separate allocation from data storage. Records such as Accounts, Cases, and custom object rows count against data storage.
How much data storage does a Salesforce Developer Edition org get?
A Developer Edition org gets 5 MB of data storage and 20 MB of file storage, with no per-user increment. That is enough for a few thousand records, so it fills up quickly if you load test data.
Why didn't my storage usage drop right after I deleted records?
Salesforce calculates data and file storage asynchronously, so large imports or deletions aren't reflected on the Storage Usage page immediately. Check again later before concluding a cleanup didn't work.
Do Salesforce sandboxes have their own storage limits?
Yes. Developer sandboxes get 200 MB of data storage, Developer Pro 1 GB, and Partial Copy 5 GB, while Full sandboxes match production. Sandboxes enforce these limits strictly, so inserts fail once you hit them.