Anyone who has worked extensively with Salesforce will tell you that it has many limitations.
A major example of this are the data storage limits Salesforce imposes.
If your Salesforce requirements are particularly data heavy, the limits on data storage will quickly become a major problem. Salesforce.com has implemented a seemingly arbitrary data storage minimum of about 2Kb / record, meaning it only takes 500,000 – 700,000 records to max out the default 1GB (or 20MB / user) most organizations are allotted. With storage space costing about $800 – $1,500 / year / GB, an application that adds 1,000,000 records / year will add $2,000 – $3,000 every year to your bill. Do this 3 years in a row, and your bill can be $6,000 – $9,000 / year higher.
The most obvious example of this problem is an integrated mass email program. If you have a list of 100,000 contacts, and email them once a month, it can add 1.2 million records each year to your Salesforce environment. This will likely make your email marketing program more expensive than you originally thought!
Why is data so expensive?
$1,500 for 1GB sounds crazy when you can go to the store and buy an 8GB flash drive for $10. In my view the cost of data storage is actually about record volume and how they impact Salesforce transaction speeds. When you run a trigger, Apex class, Work Flow rule, RSF, create or edit records, these tasks create transactions that need to be processed by the salesforce.com data center. These operations can get very computationally intensive when your Salesforce environment has millions of records. If there are too many transactions across all Salesforce customers, the system will get slower … for every Salesforce customer.
Multi-tenancy means we all need to get along
Salesforce.com is proud of their transaction speed, and they publish in on their website. Currently it takes about 0.28 seconds to process a transaction. But this speed is maintained through various limits.
In order to maintain a stable environment for salesforce.com’s 80,000+ customers, these limits are necessary to ensure transaction speed can be maintained and kept reasonable. Just imagine if it took 30 seconds to save a record because another customer was processing a job that created and modified 100,000,000 records.
To ensure we all get along in the cloud, Salesforce.com creates these limits.
If it’s about transactions: why the price per GB?
It’s true that charging for more transactions, or record storage would make more sense. It’s my belief that it’s priced per GB because Salesforce.com’s target demographic is the business user. Try explaining to a non-technical business user what a transaction is, let alone charging for them.
Salesforce.com is routinely increasing these limits to become a more attractive enterprise development platform, but for now, my recommendation is to store what’s necessary and pay for it, cleanse unnecessary records, use the API as much as possible to query very large external data sources, etc.
This will come in very handy, we have to buy more storage about every 3-4 months and now I’ll just be able to forward the request with a link to your article!
I’m hoping that Chatter storage will be excluded from data storage limits, it really adds up quickly with Feed Tracked Changes, Feed Posts & Feed Comments all counting against you…and no way to cleanse them when they overwhelm!
Hi Luke, happy I can help!
At a recent Toronto user group meeting the issue of Chatter data storage came up, the good news is that Chatter does not apply to your storage limits. You’ll notice that the chatter objects don’t appear in the storage calculations. But the speaker did mention that anything can change!
Thanks again for your comment.
Interesting eye opener post. Most of those who are developers(with DE orgs), don’t really care about this cost/gb factor.
Can you share the link, where I can see this per/GB pricing in detail ?
This document has some details : http://www.salesforce.com/assets/pdf/datasheets/DS_CustomCloud_EdCompare.pdf
This document gives available quota MBs/User, the charges above the quota are not clearly mentioned.
Hi Abhinav, Thanks for the comment. Salesforce data storage pricing is dependent on the organization, licensing, and other factors. This is why there is no clear documentation with respect to pricing.
This is a big problem, especially for nonprofit/charitable organizations who strive to reach a relatively broad constituency with a small user base. I wrote a similar article not too long ago:
http://codinginthecloud.com/2009/10/salesforce-data-storage-woes/
I have a couple of corrections 1) I believe that the storage prices you quoted of $800-1500 are per 500MB, not per 1GB, making the problem all the worse. 2) Chatter does affect storage, albeit to a much lesser extent. Chatter costs 0.25KB per post and you can find them in your storage breakdown as Feed Tracked Changes, Feed Posts, and Feed Comments.
I don’t believe that it’s practical or desirable to delete historical data–what’s the point of having a robust CRM for historical reporting if you have to regularly purge the data? Salesforce should 1) make the cost of additional data much cheaper, 2) give instances much more data storage right out of the box and 3) steadily increase data storage limits over time (think GMail). Given that they are charging for both Chatter storage and Campaign Members, a hard cap just doesn’t fit the model unless CRM is a loss leader for storage gouging.
Thanks Dave for the clarifications. When Chatter storage was discussed it was mentioned by one of the architects of the system that it would not apply. Guess that changed. At least they reduced the per-record storage. Regarding pricing, again pricing can be all over the place regrading data storage.
Great post Andrew, and a good explanation of a somewhat confusing limitation. There’s no denying that cloud solutions like SalesForce (SF) come with their own bagage, but overall I think the pro’s of such solutions can outweigh these kinds of issues. What are some of the other significant restrictions or limitations SF places on an account other than this transaction volume?
It’s worth noting to your readers that if anyone is struggling to size and determine possible future usage of their SF implementation or new Force.com project, thanks to the smarts of people like yourself on our team Architech can help people figure all that out and project SF costs, suggest optimizations and work arounds, etc. I know we’ve helped a couple of clients at least resolve some of those complexities and I hear good things!
They will reduce cost significantly on storage, ours is down to $600/500GB. We want to go to UE eventually but for now extra storage is an affordable necessity.
That said, we do wipe out old Tasks because our org generates so many that don’t warrant retention. Wish we didn’t have to but archiving doesn’t reduce storage the way a good clean DELETE [Select...]; does!
Hi Luke,
You mention that your storage cost is down to $600 for 500 GB? Is that correct? How did you manage to get such a good pricing? I am newbie to Salesforce and data storage limitions are surprising to me.
Thanks,
Padmaja