$250/GB/month: Salesforce storage math nobody does upfront

Salesforce bills data storage at roughly $250 per gigabyte per month — about ten thousand times what the same gigabyte costs on commodity object storage. The trap is that an order-heavy B2B org looks empty at go-live, then quietly manufactures gigabytes of order history until, two or three years in, an archiving project stops being optional. Nobody does that math during the license negotiation. Here is the math.

What does a gigabyte actually cost in Salesforce?

Most editions ship with a 10 GB data-storage base plus a small per-user increment, per Salesforce's own storage allocations page. Cross that line and additional data storage runs, per 2-data's public analysis as of July 2025, about $125 per month per 500 MB block — call it $250 per gigabyte per month, or $3,000 a year for a single gigabyte you forgot you were keeping. File storage is gentler at roughly $5 per GB per month. For comparison, standard object storage is priced at about $0.023 per GB per month on Amazon S3 as of July 2025.

The ratio between the top and bottom row is roughly 10,000 to 1. That is not a typo, and it is not a discount you can negotiate to zero — the per-unit economics do not move much whatever your rep pencils in. It is the standing price of keeping structured business records inside a CRM's relational core instead of on a disk. And notice which row actually bites. File storage at about $5 per GB is the one teams fret over, because attachments are visible and easy to blame, but it is an order of magnitude cheaper than data storage. The expensive gigabytes are the invisible ones — rows in your custom order and order-line objects, not the scanned PDFs everyone points at first.

Why do order-heavy B2B orgs fill up so fast?

Because Salesforce meters data storage by record count, not by bytes. Its storage page describes a Personal Edition holding roughly 10,000 records in a 20 MB allocation — about 2 KB per record — and that flat 2 KB applies whether a record carries three fields or ninety. An order line is a record. A wide order-line object with tax, promotion and returnable-deposit columns costs exactly the same per row as a skinny one, so normalising your schema saves nothing here.

Model a beverage wholesaler running 20,000 delivered orders a day at eight lines each: 160,000 order lines daily, roughly 40 million a year. At 2 KB apiece that is about 80 GB of data storage a year from order lines alone — before accounts, contacts, cases, or the field-audit trail, which quietly doubles the footprint of any object you track changes on. Two years in you are 150-plus GB over base; at $250 per GB per month that overage lands near $450,000 a year. The working set the business actually queries is a rolling 90 days; the rest is regulatory ballast you are renting at CRM prices.

Why doesn't anyone see it coming?

Three reasons, all structural. At go-live the org is empty, so the 10 GB base feels generous. The overage never appears on the initial license quote, because on day one you are not yet over. And storage accrues on a curve nobody plotted — a slow leak, not a spike — so it passes every quarterly review until the quarter it doesn't. This is the same shape as a loyalty liability compounding quietly in a spreadsheet, and the same shape as a nightly ETL that keeps working right up to the day the data volume makes it a 14-hour lie. Platform costs that accrue instead of spiking are precisely the ones that survive budgeting.

What does the archiving workaround actually cost?

When the bill finally forces a project, the standard answers are Salesforce big objects or a third-party archiving vendor, and both move the problem rather than delete it. Big objects store cheaply, but you query them through asynchronous SOQL, they do not appear in standard reports or most list views, and anything that pointed at the old records — dashboards, roll-up summaries, integrations — has to be rebuilt against a different access pattern. In practice you rebuild a slice of your reporting layer to read from two places at once. External archivers add an extract pipeline, somewhere to put the data, and a re-integration path for the day finance needs a five-year-old invoice line. Every tier you bolt on is more integration surface to own — the same trap as rebuilding empties logic in Z-tables because the platform never modelled your domain. You end up operating a data-lifecycle system Salesforce does not sell and did not warn you about.

The durable fix is architectural, not janitorial: keep only the working set — the rolling window the business queries — inside Salesforce, and let each order line land on commodity storage as an immutable event the moment it is written, so the CRM never becomes the system of record for data it was never priced to hold. That is the shape of the event-bus architecture we build, and it is far cheaper to design in than to retrofit.

Storage list prices rarely move, but data volume only travels one direction, and the order line is the fastest-growing object in any route-to-market org. The teams who stay calm about this are the ones already treating Salesforce as a workbench over a cheap, durable log — making the call themselves, before an archiving vendor's quote arrives and makes it for them.