Most Salesforce orgs get 10 GB of data storage and 10 GB of file storage per org, plus a per-user increment on top of each: roughly 20 MB of data storage per user license, and 2 GB of file storage per user on Enterprise, Performance and Unlimited. Those are the numbers behind almost every storage conversation, and they are the ones to check first when someone tells you the org is running out of room. (Allocations verified against Salesforce documentation, July 2026.)

Beyond the raw numbers, the thing that catches teams out is how the two pools are counted. Data storage is billed per record at a flat rate, so a record with 200 fields costs the same as one with two. File storage is billed by the actual size of what you upload. That single distinction determines whether cleanup, archiving, or buying more capacity is the right move.

Many organizations do not take Salesforce storage limits seriously until an upload fails or a renewal quote arrives with a storage line item on it. This guide covers the current limits, how to check your own usage, and ten practical ways to bring consumption down before you pay for more.

Salesforce Storage Limits at a Glance

Salesforce splits storage into three separate pools. They are allocated, counted and enforced independently, and you cannot move capacity from one to another.

Two details in that table catch people out. First, the per-user increment is added to the base, not instead of it, so a 50-user Enterprise org has roughly 11 GB of data storage and 110 GB of file storage. Second, if your org uses custom or feature-specific user licenses, your actual allocation may differ from the standard figures, and Salesforce advises contacting them to confirm. Your own Storage Usage page always shows the number Salesforce is actually enforcing for you.

How to Check File Storage Limit in Salesforce

Checking your limits takes under a minute and shows data storage, file storage and your biggest consumers in one place.

1. In Salesforce, click the gear icon and select Setup.
2. In the Quick Find box, type Storage Usage.
3. Click Storage Usage in the results. (In the Setup tree it sits under Data.)
4. Read the summary at the top: it shows data storage used against your limit, and file storage used against your limit, each with a percentage. The percentage column is the one to watch.
5. Scroll to the usage breakdown below the summary to see which objects are consuming the most space, and which users hold the largest files.

Using Quick Find rather than clicking through the Setup tree keeps these steps accurate across Lightning and Classic, and across Salesforce interface updates. Note that storage figures are calculated asynchronously, so a large import or bulk delete will not be reflected immediately.

1. Know Your Salesforce Storage Types and Limits

Salesforce organizes storage into three categories, each with different cost and management implications.

Data Storage

Data storage covers records in your standard and custom objects: accounts, contacts, opportunities, cases, leads, tasks, events, email message records and anything custom you have built. It is charged at a flat rate per record, which is what makes record volume, not field count, the thing to manage.

File Storage

File storage covers documents, attachments, images and files uploaded to your org. That includes Salesforce Files (every version, not just the latest), legacy attachments, the Documents tab, Chatter files, user profile photos, enhanced notes and file fields on Knowledge articles. It is charged by actual size, so it tends to grow faster than data storage and often becomes the larger problem.

Big Objects

Big objects hold high-volume historical data such as audit trails, transaction histories and long-term compliance records, and they are allocated separately from your data and file pools. Standard orgs receive an allocation of 1 million big object records, which Salesforce can increase on request. Because that allocation is separate, moving history into big objects is one of the few ways to reduce data storage without leaving the platform.

2. Salesforce Data and File Storage Limits by Edition

Your total allocation is a base amount per org plus a per-user increment, and the two storage types use different per-user figures. Salesforce’s own example: a Professional Edition org with 10 users receives 10 GB of data storage plus 200 MB, for 10.2 GB total. File storage on Enterprise, Performance and Unlimited adds 2 GB per user license, which is why file allocations grow much faster than data allocations as headcount rises.

Essentials and Starter editions are the exception on files, receiving 1 GB per org rather than 10 GB. Sandboxes have their own allocations, separate from production, which is worth remembering before you assume a sandbox error reflects a production problem.

How Record Sizes Are Calculated

This is where most storage advice goes wrong. Salesforce charges a flat rate per record that does not vary with how many fields the record has. A record with two columns and a record with two hundred columns both consume the same space.

• Most records, standard and custom: approximately 2 KB each
• Person Accounts: approximately 4 KB, because each one is a joined Account and Contact
• Campaigns: approximately 8 KB; Campaign Members are approximately 1 KB
• Knowledge Articles: approximately 4 KB, and can vary with rich text content
• Email messages: the genuine exception, sized by the actual message, so a 100 KB email consumes 100 KB of data storage

Two consequences follow. Adding a long text area field to an object does not increase its per-record storage cost, so field trimming is not a storage strategy. And images embedded in rich text fields are billed to file storage rather than data storage, which is why file usage sometimes climbs without anyone uploading an attachment. (Record sizes verified against Salesforce documentation, July 2026.)

Why This Matters for Optimization

Because data storage is priced per record, the only levers that move it are reducing record count and moving records off-platform or into big objects. That reframes the usual questions:

• High-volume objects win: a million task records cost far more than a handful of heavily customized accounts. Sort by record count, not by how complex the object looks.
• Email and activity data compounds quietly: email messages are variable-size and activity history accumulates without anyone deciding to create it.
• File storage needs a different playbook: because it is size-based, compression and offloading genuinely work there, while they do nothing for data storage.
• Watch file versioning: every superseded version of a Salesforce file keeps consuming storage until it is deleted, so re-uploading revisions of the same document multiplies its cost.

3. How to Check Salesforce Storage Usage

Checking once tells you where you stand. Checking on a schedule tells you where you are heading, which is what actually prevents an emergency purchase.

Set Storage Monitoring Thresholds

Decide in advance what utilization triggers action, for example a cleanup review at 75% and an escalation at 90%. Be aware of what Salesforce does and does not give you here: there is no native, configurable storage threshold alert on the Storage Usage page. Salesforce’s subscription terms commit to reasonable efforts to notify customers as storage approaches the maximum, but that is a contractual courtesy rather than an admin-configurable alert, and it is not something to build a process on.

To get real alerting, you need to create it: a scheduled job or flow that captures usage figures into a custom object over time, a recurring calendar reminder for an admin to check the page, or a third-party monitoring tool that polls storage and notifies you. Whichever you choose, record the numbers over time. A single reading tells you nothing about growth rate.

Visualize Storage Trends with Dashboards

Once you are capturing usage into a custom object, trend reporting becomes straightforward: chart data storage and file storage separately over time, so you can see which pool is growing faster and roughly when it will become a problem. Keeping the two lines separate matters, because the remedies are completely different.

Go Deeper with Targeted Reports

The Storage Usage page tells you which objects are the biggest consumers. Reports on those objects tell you which records to act on:

• Report on ContentDocument and ContentVersion to find your largest files and any documents with many stored versions
• Report on Task and Event for records older than your retention threshold
• Report on EmailMessage volumes, which are variable-size and often the single largest data consumer
• Use Data Loader to export record counts by object and sort by volume when you need a full picture

Match Monitoring Frequency to Your Org’s Size

Set a cadence proportional to how fast you generate records. Large orgs with heavy integration traffic benefit from a weekly check and a closer watch during quarter-end or major campaigns. Mid-sized orgs are usually fine monthly. Smaller teams can review quarterly, provided someone actually owns it. What matters more than frequency is that the reading gets logged so you can see the trend.

4. Back Up Salesforce Data Before Cleanup

Back everything up before deleting anything. Point-in-time backups mean a deletion decision that turns out to be wrong is recoverable rather than permanent.

Before any bulk deletion, run four checks. They take far less time than a recovery does:

• Retention: confirm the records are past the retention period your policy and regulators require
• Legal hold: check with legal whether any of the records are subject to hold or active litigation, which overrides your retention schedule entirely
• Dependencies: identify related records that will cascade, and roll-ups, reports or integrations that reference the data
• Recovery: verify the backup actually restores, by testing a restore rather than assuming one

Then work carefully. Process records in batches rather than tens of thousands at once, schedule the work outside business hours, and test the deletion logic in a sandbox first. Remember that deleted records sit in the Recycle Bin and keep consuming storage until they are permanently deleted or age out of it, so a deletion does not free space until the bin is emptied.

5. Clean Up Unneeded Salesforce Records

Because data storage is charged per record, removing records is the only thing that reduces it. Target the highest-count objects first, subject to the checks above.

• Old activity records: completed tasks and past events accumulate in enormous numbers and are rarely referenced after a year
• Email messages: variable-size and high-volume, which makes them the single best target in many orgs
• Stale leads: unconverted leads with no activity for years, once you have confirmed marketing does not want them for suppression
• Closed opportunities and cases: beyond your retention window and beyond the period your reporting actually covers

Don’t Overlook System-Generated Records

Some of the largest consumers are not created by users at all. Integration logs and error-handling records written to custom objects can grow to millions of rows without anyone noticing, because nobody opens them. Duplicate records from failed imports or misconfigured integrations waste space and degrade data quality at the same time. Field history and activity tracking accumulate steadily by design.

Audit these on the same schedule as user data. A custom logging object with no retention rule is one of the most common causes of a storage surprise, and it is usually the easiest to fix, because nothing depends on the old rows.

6. Archive Historical Salesforce Data

Archiving is the middle path between keeping everything in production and deleting it. It suits records with regulatory retention requirements or long-term analytical value that nobody needs in daily workflows. Historical data storage approaches range from on-platform big objects to fully external archives, and the right choice depends on how quickly you need the data back.

Identify candidates against three criteria:

• Age: older than your active reporting window, commonly two years or more
• Access frequency: not viewed or reported on in the last six months
• Business relevance: no longer referenced by active workflows, automation or integrations

Then classify what you archive by how fast you would need it back. Critical records must stay immediately accessible. Important records can tolerate a slower retrieval. Historical content must be retained but is rarely read. Define the acceptable retrieval time for each tier and the circumstances that trigger a restore, because an archive nobody can retrieve from under audit pressure is not an archive.

Build Compliance into Your Archive Plan

Retention requirements differ by industry and jurisdiction. Document which regulation drives each retention period, confirm your archive preserves record integrity and relationships, and verify you can demonstrate all of it to an auditor. An archive that cannot produce evidence of what was retained, when it was moved and who accessed it will not satisfy a reviewer, however much storage it saved.

7. Reduce Salesforce File Storage Usage

File storage is charged by actual size, so compression and offloading genuinely reduce it. Given that file storage is usually the faster-growing pool, this is often where the quickest savings are. Start by finding the biggest consumers on the Storage Usage page, then report on ContentDocument and ContentVersion sorted by size.

Compress What You Can

Images are the easiest win. Tools like TinyPNG cut file sizes substantially with little visible quality loss, and most PDF software has a compression setting that does the same for scanned documents. Set expectations with users that print-resolution files do not belong on records unless there is a specific reason. Also clear out superseded file versions, since every retained version keeps consuming space.

Offload When Possible

For large or rarely accessed documents, keep the file outside Salesforce and the reference inside it:

• External storage integrations: SharePoint, Google Drive, Box or S3, with links maintained on the Salesforce record so workflows still function at a fraction of the storage cost
• Salesforce Files over legacy attachments: better sharing controls and version management, which makes cleanup easier even though the storage is billed the same way

Don’t Forget Mobile Users

Files held externally are not available offline in the Salesforce mobile app. Before moving a category of documents off-platform, check whether field teams rely on them without connectivity. Saving storage at the cost of a field technician who cannot open a work order attachment is a bad trade.

8. Compare Cleanup, Archiving, and Additional Storage

Once you know your consumption, you have three options: reduce it, move it, or buy more. Buying more is the only one that recurs on every invoice.

Salesforce does not publish list pricing for storage add-ons, and the rates are negotiable, particularly at renewal. Third-party analyses published in 2025 and 2026 consistently report additional data storage in the region of $125 per month per 500 MB, and additional file storage at roughly $5 per GB per month, which is why data storage overruns hurt so much more than file storage overruns. Treat those as directional. The number that matters is the one on your own quote. (Pricing figures reported by third parties, current as of July 2026; confirm with your Salesforce account team.)

Work through the comparison before committing:

• Estimate cleanup ROI: multiply the hours a cleanup would take by a loaded hourly rate. If that one-time cost is less than a year of the add-on, cleanup wins outright.
• Check whether the growth is structural: if a logging object or integration generates the volume, buying storage funds the problem instead of fixing it.
• Price the archiving alternative: external archiving typically costs a fraction of native storage per gigabyte while keeping records retrievable, which is the relevant comparison for anything you must retain but rarely read.
• Time it to your renewal: storage is one of the more negotiable line items, and you have the most leverage during a contract conversation rather than in an emergency.

9. Create a Salesforce Data Retention Policy

Cleanup without a policy is a project you repeat every year. A documented retention policy turns it into a process that runs itself.

A workable policy specifies, for each major object: how long records are retained, which regulation or business need sets that period, what happens at the end (delete, archive, or move to a big object), who approves exceptions, and how legal holds override the schedule. Vague policies fail at exactly the moment they matter, so name the objects and the durations.

Support it with guardrails that shape behavior day to day. Set expectations about what belongs in Salesforce versus a document management system, train users on compressing files before upload, and document the archive retrieval procedure including who runs it. That documentation becomes valuable during an audit or an urgent recovery, when the person who designed the process is rarely the person who needs to execute it.

10. Automate Your Data Management with the Right Tools

Manual storage management competes with everything else on an admin’s list and loses. Automation makes the routine parts run without anyone remembering to run them.

• Scheduled archiving: jobs that move records matching your retention rules on a schedule, rather than in an annual scramble
• Incremental backup: capturing only what changed rather than repeatedly copying the full dataset, which keeps backup storage from becoming its own cost problem
• Usage tracking: recording storage figures over time so trends and anomalies surface early
• Granular restore: recovering specific records or objects rather than rolling back everything, which is what makes aggressive cleanup safe to attempt

Whatever you adopt, keep the controls intact. Role-based access, encryption including customer-managed keys where required, and audit logs covering every archive, delete and restore event are what let a storage program satisfy HIPAA, GDPR and SOX reviewers instead of creating a new finding.

Salesforce Storage Optimization Checklist

Work through these in order. The early steps are quick and tell you whether the later ones are even necessary.

1. Check current usage at Setup, Quick Find, Storage Usage, and note data and file percentages separately.
2. Identify your top consuming objects and largest files from the usage breakdown.
3. Log the figures somewhere durable so you can measure growth rate, not just today’s number.
4. Confirm retention requirements and check for legal holds before deleting anything.
5. Verify a backup exists and test that it restores.
6. Delete redundant records, starting with system-generated logs, duplicates and old activity data.
7. Empty the Recycle Bin so the space is actually released.
8. Archive historical records you must retain but rarely access.
9. Compress and offload large files, and clear superseded file versions.
10. Document a retention policy and schedule the whole cycle so it repeats without prompting.

Don’t Let Salesforce Storage Limits Limit Your Growth

Managed proactively, Salesforce storage limits are a planning input rather than an emergency. Teams that check usage on a schedule, hold a documented retention policy, and archive deliberately avoid the two expensive outcomes: a rushed add-on purchase negotiated from a weak position, and a cleanup done under time pressure without proper backups.

Large data volumes also affect how the org feels to use. Reports that scan millions of aged rows, list views cluttered with records nobody needs, and search results buried under years of closed activity are all consequences of volume rather than of the storage limit itself. Reducing that volume improves those experiences, which is a separate benefit from the cost saving and worth making the case for on its own terms.

This is what Flosum Backup & Archive is built for. It runs inside Salesforce, captures only what has changed to keep backup overhead down, provides granular restore when a deletion turns out to be wrong, and moves aged records to lower-cost storage while keeping them retrievable, with audit trails covering every archive, delete and restore.

See how Flosum Backup & Archive can reduce your storage consumption while keeping historical data accessible and audit-ready. Request a demo to walk through it against your own org’s numbers.

Frequently Asked Questions (FAQ)