Salesforce Data Storage Basics. How to Manage Costs and Control Limits

Salesforce offers two kinds of storage for digital information: data storage for records, and file storage for files and attachments. Each has an upper storage limit set by your edition and the total number of user licenses. Once that limit is reached, companies have a choice between purchasing additional storage for a substantial cost on top of everything and managing storage usage by archiving older records or deleting unneeded information.

The most valuable business resource varies depending on the industry, timing, and other factors. In a modern society, information has long since become the most prized possession for the majority of existing businesses. Being able to efficiently gather, analyze, and process information is one of the biggest goals for most businesses.

Yet, managing information at scale is far from an easy task, with many businesses having a hard time achieving said goal. It is an especially popular topic when it comes to one of the Customer Relationship Management solutions like Salesforce. The average cost for Salesforce storage is extremely high, and there are many limitations to the way Salesforce’s data storage capabilities work that would prevent some of the existing data-saving methods from working.

Data management is not something that can just be ignored in the long run, either. Low performance, problematic data integrity, and expensive storage expansion plans are just a few examples of how this can affect average CRM users. In this context, a proper understanding of Salesforce’s data storage capabilities is essential, including all the limitations and unique characteristics.

What is Salesforce Data Storage?

Salesforce data storage is your available storage space for holding CRM records like accounts, contacts, opportunities, cases, and custom object data. Data storage is billed separately from file storage, and the exact amount you get varies based on your edition and the number of user licenses in an org.

The majority of records occupy about 2 KB each, so the standard 10 GB base allocation can store roughly 5 million records. That said, you will probably hit the capacity limit before you hit the number of records as the volume of records grows over time. 

The way data storage differs from file storage will be covered in later sections.

Where does Salesforce Store Data?

Your records are kept on Salesforce’s own cloud platform as data storage. Files and documents you upload are kept as file storage, with Big Objects being treated as a separate category for very large datasets. Data that you don’t use regularly may also be archived to external storage under your control.

The Salesforce platform categorizes all user-provided information by type. If the data in question is records from either standard or custom objects, they count toward the data storage limit. You also have items that are uploaded directly into the environment, like Salesforce Files, attachments, or documents, that count as file storage instead. All large, long-term datasets can go into the Big Objects category that has its own storage limitations.

All this exists in production Salesforce storage, with every GB of data eating into your limit and your bill. As a result, some organizations choose to store their older, infrequently-used records and files outside of the platform and in the external storage they themselves own, like a cloud object store. The effectiveness of this strategy depends on how quickly and easily you can access and pull back the archive data – a topic we’ll cover in the archiving topics below.

What is the Difference Between Salesforce Data Storage and File Storage?

Data storage holds a company’s actual data, such as accounts, opportunities, cases, and custom object data. File storage exists for the uploaded content in the same organization, be it Salesforce Files, attachments, documents, or Chatter files. Salesforce provides separate limits for these groups, so freeing up space in one can’t compensate for the shortage in the other.

Data storage in Salesforce can be separated into two large groups, with the addition of a third theoretical option called Big Objects that rarely gets used outside of enterprise-scale environments of immense complexity.

• Data storage represents a part of Salesforce’s storage space that holds data – contacts, accounts, events, opportunities, and so on. Most records only take about 2 kilobytes of storage, but some specific types are bigger: person accounts are about 4 KB, while campaigns take up to 8 KB. Email messages remain in their own ballpark due to the variable size of their attachments.
• File storage is a group that covers the entire range of files uploaded into Salesforce, be it photos, attachments, assets, and many other examples. It includes Salesforce Files, attachments, documents, Chatter uploads, and images embedded into rich text fields.
• Big Objects is a category of custom objects that can store massive data volumes with virtually no performance losses. Common examples of such data include financial transactions and IoT data, among others. These objects are in their own ballpark in the eyes of Salesforce – up to 1 million records per org in eligible editions (without counting as part of data storage).

Protect all of your Salesforce Big Objects
Learn more

Your uploaded file’s format will determine its label. Files are the default, contemporary method of sharing and storing content. Attachments have their origins in the legacy file type in the Notes & Attachments related list that still exists in older orgs with extensive history. Documents are stored using the legacy Documents tab. All three variations take the same pool of file storage, though, so you are effectively managing this one limit if you try to find how many documents Salesforce can hold.

The real difference is in scale. By definition, you’ll have many more records than files, but single data storage units hold many more individual records. Salesforce counts these separately, with independent limits: you might exceed your file storage limits but have room in data storage or vice versa. That said, the extra capacity for different storage types also has different prices, as covered later in the cost section.

Storage type	What it contains	How limits are calculated	Typical reasons it grows
Data storage	Records from standard and custom objects (accounts, contacts, opportunities, cases, tasks)	Org-wide base (10 GB for most editions) plus a per-user allowance (20 MB per user on Enterprise)	Record volume growing over time from activities, cases, integrations, and automation
File storage	Salesforce Files, attachments, documents, Chatter uploads, images in rich text	Org-wide base (10 GB in most cases) with a per-user allowance (2 GB per user in Enterprise)	Documents, media, and email attachments
Big Objects	Very large volumes of historical or log-style records like IoT data or financial transactions	Allocated separately, 1 million records per org where applicable	Long-term, high-volume data

Big Objects are supposed to work with billions of records with ease, but it is also not the ideal storage option, either. They can only be updated in an asynchronous fashion, and they are incompatible with Validation Rules, Workflow Rules, and several other automation tools from Salesforce.

What are Salesforce Storage Limits?

Salesforce storage limits exist separately for data storage and file storage. All Salesforce editions get a base allocation of both per org (usually 10 GB), combined with a per-user allowance. Your total storage limits depend on your edition and contract, with the possibility to buy extra storage if necessary.

The amount of storage space Salesforce data can take is only a part of the issue. Another noteworthy part is the total storage volume that Salesforce allocates to an organization. The majority of Salesforce licenses receive 10 GB of file storage and data storage each, along with additional storage calculated from the number of user licenses attached to an organization. The exact storage volume per license would differ greatly depending on the license level and other factors. 

Salesforce determines your limits in a few steps, repeating them separately for file storage and data storage calculations:

1. The baseline is the allocated storage volume for your edition (most orgs get 10 GB of each, with exceptions like Essential or Starter getting 1 GB of file storage only).
2. Then the per-user allowance is added to the total depending on the number of eligible user licenses. For example, an Enterprise license adds 20 MB of data storage and 2 GB of file storage per license.
3. What follows is all the extra storage purchased from Salesforce being accounted for.
4. The result is two separate totals for data and files respectively, each measured against its own usage.

Let’s use an average Enterprise org as an example, with 49 eligible user licenses resulting in 10 GB + (49 x 20 MB) = 10.98 GB of data storage and 10 GB + (49 x 2 GB) = 108 GB of file storage.

The table below presents the majority of storage allocation limits that Salesforce provides to its end users. N/A marks mean that the specific edition doesn’t offer per-user storage.

Salesforce edition	Data storage per organization	Data storage per license	File storage per organization	File storage per license
Essentials	10 GB	N/A	1 GB	N/A
Personal	20 MB		20 MB
Starter	10 GB		1 GB
Contact Manager		20 MB	10 GB	612 MB
Group
Professional
Enterprise				2 GB
Performance		120 MB
Unlimited
Developer	5 MB	N/A	20 MB	N/A

Contact Manager, Group, and Professional orgs with less than 10 users get 1 GB of file storage per user instead of only 612 MB. Note that some custom or feature-specific user licenses can add less storage than the standard license, so it’s best to check your Storage Usage page to see the actual limit Salesforce grants to you. Allocation figures are based on Aquiva’s 2026 storage cost breakdown.

The exact limitations and other information are subject to change; visit Salesforce’s help page to learn up-to-date information. It should also be noted that different Salesforce licenses also have their own limitations when it comes to certain actions – number of custom objects, number of external objects, number of fields, and so on. Learn more on the dedicated Salesforce help page.

If the included allocation isn’t enough, any org can buy additional storage from Salesforce, which will be covered in the next section.

How Much Does Salesforce Data and File Storage Cost?

Salesforce doesn’t officially publish its extra storage prices, but there are many reports from customers stating that 500 MB of data storage costs about $125 per month, while 1 GB of file storage costs about $5. Data storage costs seem to be roughly 50 times higher on a per-GB basis than file storage. Actual prices may differ depending on contract terms.

Purchasing additional storage from Salesforce itself when you are close to your current limits seems like an obvious option. The process of doing so is also simple – go to Setup > Your Account > Browse & Buy and locate the storage options. While you are most likely bewildered by the storage price, we would like to go over several important factors:

• Salesforce storage is extraordinarily expensive, and the cloud-centric nature of the platform means that the storage cost is added to an organization’s spending as a monthly or annual payment instead of a one-time purchase.
• File storage and data storage have different pricing points, with the latter being the more expensive of the two (considering how small is the size of an average record vs an average file).
• Contract terms could affect the final price, with negotiated prices varying wildly while annual commitments or bulk purchases usually bring discounts.

While comparing storage options, don’t just look at the per-GB price. Instead, try to imagine whether it’ll be better for you to buy additional Salesforce storage, continue to accumulate data over time, delete what’s genuinely unnecessary, move less-active data into low-cost storage, or archive data while keeping access to it for edge cases.

As Salesforce doesn’t publish its own prices, the rates here are customer-reported 2026 figures taken from Aquiva. We’ll take the previously-mentioned example of an Enterprise org with 49 users from the previous section for a consistent example. 

Estimating its 10.98 GB of records at $250 per GB would result in roughly $2,745 a month, while the 108 GB of files at $5 per GB would add $540 more for a total of $3,285 per month (or $39,420 a year). The same 119 GB of storage in AWS S3 Standard would cost about $2.74 a month at a standard cost of $0.023 per GB per month with a grand total of $32.84 per year – roughly 1,200 times less than the cost of Salesforce’s internal storage. That said, this example only values the org’s included allocation at Salesforce’s marginal rate instead of describing an actual invoice, and it also only covers storage at rest.

See the full Salesforce storage cost comparison.

With prices like these, it might be a wise idea to consider a third-party alternative as a means of storage expansion, with cloud providers such as Amazon offering storage at a far lower per-GB price than Salesforce.

How Do You Check Salesforce Storage Usage?

Open Setup, search for Storage Usage in Quick Find, and select it. The page in question offers an overview of data and file storage available and used, along with usage by record type and top users. Files that take the most storage are marked separately. Both Manage Users and Manage Internal Users are necessary to view this page. If the recommendation to purchase more storage is out of the question, the next obvious piece of advice would be to monitor the state of your Salesforce storage on a regular basis. 

Fortunately, storage usage monitoring features in Salesforce are relatively simple, as they don’t offer much outside of a detailed breakdown of your Storage Usage page. Here’s a detailed explanation of how to find it:

1. Open Salesforce Setup.
2. Enter Storage Usage in the Quick Find box and select it when found.
3. Take a look at data storage and file storage separately to compare what’s used with what’s available.
4. Check usage by record type and the largest files to try and find the reason for excessive capacity consumption.
5. In order to see what a single person’s contribution is, go to Setup > Users, open a specific user, and click the View button next to either Used Data Space or Used File Space.
6. Try to analyze the figures at regular intervals to compare how fast the storage consumption is growing against how much of it remains.

This single screen provides a centralized source of information on how your organization works with storage in Salesforce, including storage usage per data, file, or big object, as well as the list of top storage consumers. Note that Salesforce uses an asynchronous calculation method to measure data and file storage, so the values you see might not update immediately after a large import. If you want to view file storage accurately, you’ll also need the specific permission called Query All Files.

This is as far as Salesforce’s native capabilities go. There are no configurable threshold alerts for storage, either, and anything like a history of custom reporting or customizable alerts is only possible via a third-party solution or a custom check created via REST API or Apex.

What Happens When Salesforce Storage is Full?

Production orgs aren’t immediately paralyzed once they reach 100% storage capacity. Salesforce starts showing the STORAGE_LIMIT_EXCEEDED warnings, and the org keeps working, but the overage becomes a contractual issue at that point, with potential problems surfacing indirectly. Sandboxes are much stricter than production orgs, blocking saves and uploads as soon as the limit is reached.

Salesforce itself has a very unconventional approach when it comes to exceeding storage limitations. They try to notify you as best as they can before you reach your maximum, but there isn’t actually a native, configurable threshold alert. It doesn’t hard-block the production usage once the limit has been reached, either – shutting down a live CRM would be much worse than the consequences of an overage.

That doesn’t mean going over is tolerable. That way, the overage turns into a contractual matter that you’ll have to handle via the account team instead of basic Support. The practical effects of being over the storage capacity tend to appear indirectly, with slower reports, errors in workflows,  API integrations being unable to read/write, slower queries, and so on. Some businesses even report not being able to create records or upload files after going over the limit, with an error message stating the obvious: “no more data creation until storage is reduced.” 

As such, keeping an eye out for general storage consumption in Salesforce is highly recommended for a number of reasons that have the potential of significantly disrupting the operational state of an organization. 

If you do go over, though, there aren’t that many choices to work with: 

• Buy more storage;
• Delete outdated records or files;
• Move older data out of production.

The preferred option would be to purchase additional storage in advance or create a data archiving solution.

How Can You Reduce Salesforce Storage Costs?

Lower your costs for Salesforce storage by purging data you don’t need and archiving older items to cheaper storage. Monitoring data growth regularly isn’t a solution to this issue like others, but it does help with being aware of your current storage capacity to avoid being surprised by storage space running out all of a sudden, forcing drastic measures.

The easiest way to free up some space is to consistently get rid of everything that doesn’t have to be there, and a few habits can help you keep it that way:

• Records that don’t matter for compliance or reporting can usually go, especially if they are barely used or were duplicated years ago.
• To identify records like these, open the Storage Usage page: it offers record counts per object, with the objects on the top being the ones that use the most storage space.
• Establishing a duration of how long each data type would stay in production creates a consistent point at which older records and files are either archived or removed.
• You may also archive records that are rarely opened by users, or the oldest/largest files in the org.
• Usage monitoring on a consistent basis would serve well to keep the effectiveness of your efforts.

Growth tends to be a lot easier to prepare for when you see it coming. The overarching goal here should be to stop paying production rates for storing data that rarely gets used on a daily basis.

Deleting information might be easier than archiving, but it’s not always the best option to go with. Historical data in Salesforce might have some value as compliance, operational, analytical, or even AI data, which is why archiving remains the preferred option in such cases.

Our best practices section below goes into both these options in more detail, and the buy-or-archive section before it can help identify which one makes the most sense for you.

Should You Buy More Salesforce Storage or Archive Your Data?

There isn’t a clear answer to whether buying more Salesforce storage or resorting to Salesforce data archiving is the undisputed best option. If your ultimate goal is to keep the data in constant use, buying more storage would be unavoidable. Archiving works better for older and rarely-used data that still has to remain accessible. No one would stop a company from using both options simultaneously, either.

The bottom line is all about the data itself. Above all else, you want to think about how frequently users are opening historical records and how quickly the storage consumption grows. Retention and compliance requirements are one step lower on the priority ladder, followed by the need to reach the information instantly. Long-term costs and reporting for analytics should play a part in some way, too, along with any plan to reuse historical data later for something like AI training.

The comparison below offers a direct face-off of both methods side-by-side.

Factor	Buying more Salesforce storage	Archiving older data
Immediate capacity	Adds capacity directly in Salesforce	Frees capacity as older data moves out of production
Ongoing cost growth	A recurring charge steadily increasing with data volume	External cloud storage tends to be extremely cheap (about $0.023/GB per month in AWS S3)
User access to historical information	All data remains in place and visible	Depending on the setup, some users with in-app access can still open archived records and files in Salesforce
Effect on production org size	The org keeps growing	The org can shrink to what teams use daily
Long-term scalability	Cost grows with volume	Volume can keep growing outside Salesforce without increasing the internal storage bill
Data ownership / storage location	Data stays in Salesforce	Data sits in storage your organization owns and controls

A certain degree of customization would be needed to use a cloud provider’s storage alongside Salesforce. Manual integrations are a possibility. That said, solutions like GRAX make it simple to migrate data to third-party storage and access it from within Salesforce using Lightning Web Components. GRAX Archive, for example, migrates older records and files to the storage solution of your choice while keeping the possibility of restoring them to Salesforce.

The Salesforce Storage Savings Calculator allows you to evaluate your potential annual storage cost savings acquired by analyzing the number of records and files your company might consider archiving off-platform.

Estimate your Salesforce storage savings with the Salesforce Storage Savings Calculator.

What are the Best Practices for Managing Salesforce Storage?

The core ideas for managing storage in Salesforce are to clean up unused data, monitor usage regularly, archive older information, configure retention policies early on, and actively use features like Custom Settings or Record Types to avoid redundant data creation. The importance of each piece of advice will vary depending on a specific company’s growth rates and retention requirements.

The context of Salesforce data allows us to treat both storage optimization methods and storage cost reduction methods as essentially one and the same since they both lead to the same goal. With that in mind, we can present a number of valuable recommendations on how Salesforce storage can be optimized for lower data consumption.

Implementation of Record Types

Record Types is a feature of Salesforce that can improve the record management process in certain ways. This method might not provide a direct effect when it comes to storage reduction, but it does contribute to storage management indirectly by providing better information organization and reducing data duplication.

Record Types can be used in data categorization and field layout customization, but the most notable advantage of this tool is to customize all kinds of fields, processes, and layouts for the same object in different categories, dramatically reducing the number of records and custom objects that have to be created.

Attachment compression

Attachments and other file types uploaded to Salesforce can take a significant amount of space, even if they are stored in a separate storage environment. Compressing the biggest files in a Salesforce environment can offer dramatic storage savings with a relatively low effort.

The easiest way to do so is the manual compression method. It includes downloading large attachments to a local workstation, compressing them using one of many tools such as WinRar or 7Zip, and then uploading the compressed attachment back to Salesforce while deleting the original.

The method in question might seem relatively easy, but it also has a lot of downsides to it:

• Potential security risk;
• Performance loss while working with compressed attachments;
• Long time required to process large attachments;
• Compatibility issues with common archive formats.

Data compression as an industrial feature might also be present in certain third-party data management solutions, but their capabilities and limitations would also differ drastically from one case to another, as would their advantages. 

Data storage solutions vary in their approach to managing Salesforce attachments and their associated costs. While some solutions focus on compression techniques with varying degrees of complexity and trade-offs, alternative approaches like GRAX offer a more straightforward solution: archiving attachments directly to customer-owned cloud storage while maintaining accessibility through Salesforce’s Lightning Web Components. 

This approach eliminates the need for complex compression rules or decompression delays, reducing platform storage costs while ensuring users can still seamlessly access their attachments through the Salesforce interface.

Data archival

It would be fair to mention that data compression and data archival in the context of Salesforce are completely different processes, even if both of them use the term “archive” to a certain degree. Data archiving in Salesforce is a process of collecting outdated or irrelevant information and moving it to a dedicated location without cutting access to said information. 

There are multiple approaches that Salesforce can take to archive information:

• Manual archiving.
• Built-in data archiving capabilities (Big Objects).
• Data extraction into a data warehouse.
• Salesforce Archive – a native archiving solution.
• Third-party solutions for data archiving. 

Each method has its own use cases and limitations (with the aforementioned Big Objects being one of several built-in archiving measures that are rarely protected by third-party solutions themselves). 

Backups for Big Objects are surprisingly uncommon when it comes to the market of third-party backup software for Salesforce, and the reasons for that are not entirely clear. To this day, GRAX remains one of the few solutions on the market that offers complete protection to Salesforce data, including Big Objects.

Archiving as a whole also has a few overarching disadvantages, such as:

• The limitation on the number of records stored (1 million records stored in Big Objects for a single organization).
• Risk of losing information during the archiving process (mostly relevant to manual archiving methods).
• Limited availability (Big Objects is only available to certain Salesforce licensing tiers, so check whether yours fits beforehand).
• Potential impact on Salesforce performance (archived information is stored in a compact form and is often stored in a slower storage than the primary Salesforce environment).
• Lackluster feature set (Salesforce Archive operates as a native solution but might not be flexible enough to cover the needs of more complex organizations).

As a result, archiving is not a definitive solution to storage consumption issues, but it can improve the situation to a certain degree, improving system performance and reducing storage consumption in the primary Salesforce environment while remaining compliant with various regulations and legal frameworks when it comes to sensitive information. 

However, third-party archiving solutions like GRAX can cover the gaps in Salesforce’s native capabilities.

Data cleanup

Something as simple as a data cleanup can also be used as a means of saving storage space. Unused fields and records are one such example, with Salesforce being able to identify those with relative ease. The data in question can be deleted manually or using a dedicated tool (be it from Salesforce or from a third party).

While there is a Recycle Bin functionality in Salesforce, it can only hold data for 15 days at a time, and there is no way to restore information once it has been erased from the Recycle Bin. However, this kind of limitation is only relevant to the built-in measures of Salesforce, which also have a number of other limitations that are worth mentioning. For example, the Mass Delete option cannot delete different record types in the same operation and does not allow for over 250,000 records to be deleted at once.

The same logic can be applied to AppExchange apps – they can be limited in terms of what they can delete and might also require additional time to purchase and configure before being operational and useful. 

The fact that Salesforce operates as an interconnected web of records and objects does leave the possibility that mass deletion might break certain relationships, creating all kinds of unpredictable issues as a result. Some organizations in certain industries will also be prevented from deleting certain information if they are subject to compliance or regulatory frameworks.

Custom settings implementation

The usage of Custom Settings in Salesforce is another way to improve redundancy by storing and managing configuration information outside of standard objects. Custom Settings data doesn’t count against regular data storage. It has a dedicated cached data limit instead – the lesser of 20 MB or 2 MB per full-featured user license, a fitting option for small configuration values.

Custom Settings make it possible to access frequently used data without relying on long-form SOQL queries, improving data management efficiency. The ability to centralize common values in Custom Settings also drastically reduces the number of redundant records in Salesforce databases, saving storage space as a result.

Data retention policies

Salesforce data retention policy as a feature can help a lot with managing Salesforce storage in the long term since it can be used to either delete or archive certain data formats or records after a specific period of time. 

The fact that only the most relevant information is kept in the Salesforce storage not only improves the overall storage management capabilities but also reduces the possibility of a storage limit being exceeded.

There is also the topic of company-mandated policies about data retention, with certain companies in the financial services department having a strict requirement on all data being stored for a certain number of years before it can be deleted.

However, these policies have to be configured with a certain degree of thoroughness to avoid unintentional deletion or archiving. There is also the fact that Salesforce can only provide a very small selection of automation capabilities for data retention purposes (mainly custom automation created using Flow; Process Builder and Workflow Rules have both reached EOS on December 31, 2025). 

As such, the only reasonable avenue for in-depth data retention management would be to look into purchasing a third-party data management solution, explained in more detail below.

Which Tools Help Manage Salesforce Storage?

The native data management tools in Salesforce include Data Loader, Mass Delete, Storage Usage page, Salesforce Backup & Recover, and Salesforce Archive. Third-party tools like Spanning or GRAX are commonly used to expand on what the native tools can and can’t offer.

Native Salesforce data management tools

Salesforce offers a respectable selection of built-in tools for data management and similar tasks. They can be used to monitor data usage, automate cleanup, and streamline data management workflows. Five of the most noteworthy examples of such tools are:

• Data Loader makes it possible to manage large data volumes in bulk; it can export, update, insert, and delete information at scale. It is a great tool for deleting or moving unnecessary information, reducing the time it takes to free up valuable storage space for other purposes.
• Mass Delete is much more case-specific; it can only delete different records in standard objects, one object type at a time with up to 250 records per operation, and practically nothing else. The primary use case for Mass Delete is to clean up unused or old records that take up storage space, which can be used for other purposes.
• Salesforce Optimizer was a reporting solution for some Salesforce instances that was retired back in the Winter ‘26 release. Instead, Salesforce now recommends utilizing the Storage Usage page for identifying what fills up your data storage. There’s also the free Salesforce Labs app called Org Check that aids in analyzing your metadata. These tools are now used to spot all the different options for bringing storage consumption down before it reaches its limits.
• Salesforce Backup & Recover (formerly known as Own Recover) is a native backup solution in the Salesforce environment. It can automate backups, restore a select number of specific objects, export information in formats like CSV, and more.
• Salesforce Archive is one of the more recent developments in Salesforce’s native toolset that offers data management capabilities for organizations with large data sets. It has a number of useful capabilities, including custom archiving policies, comprehensive monitoring, and seamless data access. The native status of the solution also makes it adhere to the strict security policies of the Salesforce environment, making it easier to achieve compliance with many data retention regulations.

None of these tools is particularly complex or sophisticated, which also simplifies the recommendations when it comes to their usage. Regular checks of the Storage Usage page can offer a multitude of information about the current state of the storage, while the usage of Mass Delete or Data Loader can help with managing large portions of the storage with an impressive level of convenience. Salesforce Backup & Recover and Archive can offer basic backup and archiving capabilities, respectively, making them a convenient option for smaller or less complex businesses without intricate demands when it comes to data security or retention. Both of these last two options come from Salesforce’s acquisition of Own (OwnBackup), whose tools are now integrated into the Salesforce product suite.

Third-party Salesforce data management tools

The true versatility in terms of data management and data security for Salesforce comes in the form of third-party solutions and applications. These solutions often provide an extraordinary feature set that vastly exceeds the built-in capabilities of Salesforce in certain areas – be it data management, disaster recovery, etc. Here are a few examples of such software:

• GRAX is a powerful data management solution for Salesforce. It combines storage management capabilities with extensive data archiving and in-depth backup tasks, built to cover the full lifecycle of information from its creation to deletion. The data archiving ability alone can dramatically reduce total storage costs while also retaining the company’s access to outdated information that might be useful for some purpose in the future – and all of that is without leaving the Salesforce UI.

The exact feature set of each solution differs in most cases, but the majority of basic use cases stay the same, and storage management improvements are always on the top of that list.

Version control and data compliance are just a few examples of how third-party backup software can assist with Salesforce’s data storage management tasks. Add that to the aforementioned combination of backups, disaster recovery, archiving, and data security – and it would become clear why the involvement of such solutions is highly advised in many situations.

Frequently Asked Questions About Salesforce Storage

Is it possible to set up automatic archival rules with Salesforce’s built-in capabilities?

While Salesforce can offer both manual (Big Objects) and automated (Salesforce Archive) data archival capabilities, they might not be versatile or flexible enough for organizations with complex environment structures or specific data retention requirements. As such, the involvement of third-party archiving solutions is still recommended to most large organizations in Salesforce.

Can Salesforce data be archived outside Salesforce?

Any kind of compliance risk is only possible if the third-party storage solution itself is not compliant with a specific regulation, be it GDPR, HIPAA, etc. Luckily, most major cloud storage environments do have the capability to offer all the necessary security levels to be compliant with specific standards. 

How much Salesforce storage do you get per user?

The exact number differs depending on your edition. Most start with 10 GB of data, and for files, adding an allowance per user license on top of this: 20 MB of data and 2 GB of files (for Enterprise), for example. The limits section above provides a list of all editions with their respective data allowances.

How can you reduce Salesforce storage without deleting historical data?

Archiving is the preferred option. Clearing out the production storage from older records frees capacity without deleting important historical information, and archived data itself can still be accessed from Salesforce. Retention rules determine what is archived and when, with oldest and largest files often being the first ones to go.