Data is being added to your Salesforce org every day. And probably lots of it. But do you really know (truly, honestly, deeply) how many records are in your Salesforce org? Or maybe the better question is, why should you care?
Each record in your org has an associated storage size and counts against your allowance/limits. Since storage is not unlimited, you’ll need to pay for more if you go over your limits.
But more importantly, the number of records you store in Salesforce affects the performance of a number of activities in your org, including report run times, rendering list views, SOQL/SOSL query responses, Apex job runtimes, data exports, backup runtimes, and more. Performance issues, as well as a Production org cluttered with old or obsolete data, will always impact the business users in some way shape or form, which can adversely affect trust and system adoption. Check out this article to learn more about Salesforce adoption.
How much storage space do records consume?
For most objects, the standard rule of thumb is that each record takes up 2Kb of storage space. That 2Kb is best thought of as a “total reserved size” for the record - the actual storage space used could be less if the full 2Kb isn’t used (because not all fields on a record are filled). Some objects consume 4Kb or 8Kb of space per record. You can find more details about Salesforce record sizes here.
If you work in Salesforce regularly, you might be familiar with the Storage Usage page in the “Setup” area. While this page is a great resource, it only shows you the objects whose storage counts towards your Salesforce storage limits (it also shows the “total reserved space size” of those objects as mentioned above).
For example, it doesn’t show you the record counts for all objects in the org, because some objects aren’t counted towards the storage usage and limits (such as Assets and Opportunity Lines Items). The list of objects that do count towards your storage usage and limits can be found here.
So, for certain objects, you can store as many records as you need and they will not count towards your storage usage and limits. Great, free storage! Well, yes, but don’t forget the earlier point around performance implications and their impact. The more records you have, the better chance that they will impact performance.
It all means that the numbers in the Storage Usage page in Setup are only showing you a subset of the actual number of records and their storage sizes in your org.
How to get an accurate record count of the objects in your org
One of the best and easiest ways to do this is to use the recordCount API that Salesforce offers. The full documentation is here. You can easily run the API in Workbench or Postman. The API’s response gives a JSON output containing the record counts for each object in the org in order to provide that more complete view.
There are some records that aren’t listed in the API’s response such as Archived Activities, records in the Recycle Bin, History tables, Share Tables and Feed Items. If you want to get a count of these items then run manual SOQL queries to get the counts (e.g. Select Count() from AssetHistory) and then add them to the sum of the records from the recordCount API.
Another way to have a clearer picture of your total record count is through your Salesforce backup solution. At Own we are frequently asked the following questions about storage usage and record counts:
Why is the backup size and record count different to what Salesforce in showing in Storage Usage?
We back up all of the objects in the customer’s org, regardless of whether Salesforce counts them towards storage usage. This is to ensure that you are able to precisely restore all objects and records whenever you need to.
Why is the storage for an Object different between what Salesforce is showing in Storage Usage versus what the backup stats are showing?
The backup application shows the actual size of the storage for an object’s records in the backup, not the standard reserved size of 2kb per record that Salesforce shows (such objects may have a reserved size greater than 2kb, see this article). Typically the size of the records in the backup is less than what Salesforce shows, as not all records will use the full 2Kb allowance.
What's contributing to data growth in your org?
Now that you can better understand how many records you currently have against all of the objects in your org, you may want to also consider how quickly your data is growing.
While data can grow exponentially in any area of your Salesforce org, we tend to see the fastest growth in objects like Tasks, Emails (including messages, templates, images), Statements of Work (SOW), Requests for Proposals (RFP), Proposals, and Cases. We also see the volume of data grow when companies are storing highly transactional data (like with the use of Salesforce CPQ), or if their Salesforce org is connected with other applications via integrations.
In addition, the need to comply with industry or government regulations can also require companies to store large amounts of data for a designated period of time.
How to optimize system performance AND reduce storage costs
Your first instinct might be to manually identify and delete some of the records. However, this option creates a lot of tedious and inefficient work for the internal team responsible for the data, and could potentially put your business at risk. If you go down this route, make sure you have a backup that you can easily recover from if you ever need it!
A more prudent solution would be to archive your data. As your Salesforce data grows, an archiving solution is the only long-term, scalable solution for managing the lifecycle of your data.
One scenario you will undoubtedly face is the need to remove records from the org, while still retaining and accessing those records for compliance and operational purposes. With Own Archive, for example, you can relocate data from Salesforce into Archive storage, meaning data is retained and can still be accessed live within the Salesforce UI by the business users.
Archive also allows you to analyze which objects are taking up the most space in your org and the breakdown of your Salesforce storage usage versus what has been reallocated into Archive storage (which is unlimited).
“With Own Archive, I am able to keep our system performance high by reducing clutter and safely storing the data needed for compliance purposes outside of our production environment.”
Brie Murphy
Manager, Sales Support, Workwear Outfitters
This helps optimize the performance in Salesforce, as the storage is reduced. For the objects which do count toward the org’s storage limits, Archive will also help reduce that usage. To learn more about Own Archive, contact us below.
