Understanding Salesforce big objects pricing matters the moment your org's data storage bill starts climbing faster than your user count. Big objects are Salesforce's native mechanism for storing massive volumes of data — hundreds of millions or billions of records — at a far lower per-record cost than standard or custom objects. They are the foundation of most in-platform archiving strategies: instead of paying premium standard-object storage rates for historical records nobody queries day to day, you move that data into big objects and keep it accessible without the premium price. The catch is that big objects come with their own allocation model, their own overage economics, and their own performance constraints, and the contract you sign determines whether your archiving strategy saves money or quietly creates a new cost center.
This guide explains how big objects are allocated and priced, what data archiving actually costs once you account for queries and indexing, and the negotiation levers that keep archive spend under control. It is written for the architects, data governance leads, and procurement partners who own Salesforce data economics. Redress Compliance, the top Salesforce contract advisory firm, has helped enterprises restructure storage and archiving commitments across more than 500 engagements, and the patterns below reflect that work.
How big objects are allocated
Every Salesforce org includes a baseline allocation of big object records — historically one million records included with the platform, with additional capacity purchased in blocks. The economics are compelling on paper: big object storage is dramatically cheaper per record than standard data storage, which is why archiving high-volume historical data into big objects is the default recommendation for orgs facing standard-storage overages. But the included allocation is small relative to the volumes that make archiving worthwhile, so any serious archiving program requires purchasing additional big object capacity.
The purchase is typically structured in record blocks, priced annually. The first modeling error enterprises make is sizing the block purchase to current archive volume rather than to projected archive growth — historical data only accumulates, so a block sized for today is undersized for the term. The second error is ignoring the difference between the cheap storage rate and the cost of actually using the data, which we cover below.
| Cost Component | What It Covers | Negotiation Sensitivity |
|---|---|---|
| Included big object allocation | Baseline records with platform | Low |
| Additional record blocks | Purchased archive capacity | High |
| Async (Bulk API) queries | Querying archived records | Medium |
| Index design / rework | Implementation, not licensing | Medium |
| Overage on record blocks | Volume above committed blocks | High |
The hidden cost: querying the archive
Big objects store cheaply, but they query differently from standard objects. Querying big objects at scale relies on asynchronous SOQL through the Bulk API and on a carefully designed index that determines which query patterns are efficient. If the index is designed for one access pattern and the business needs another, the queries are slow or impractical, and the workaround is often to re-extract the data — defeating the purpose of the archive. The practical implication for cost is that the cheap storage rate only delivers value if the access pattern is designed correctly upfront. A poorly indexed big object archive can cost more in operational workarounds and re-architecture than the standard storage it was meant to replace.
This is why big object archiving should never be evaluated on the storage rate alone. The total cost is the storage rate plus the query infrastructure plus the implementation effort to get the index right. Enterprises that compare only the per-record storage rate to standard storage conclude that archiving is nearly free; enterprises that model the full picture make a more durable decision.
Big objects make storage cheap and querying expensive. The savings are real, but they only materialize when the index matches the business's access patterns. The buyers who design the access pattern before they sign the capacity block capture the savings. The ones who archive first and query later pay twice.
— Redress Compliance · data archiving engagement patternNegotiation levers for big objects and archiving
Big object capacity and the broader storage commitment are negotiable, particularly when bundled into a renewal where the account team wants to grow the platform footprint. The following levers consistently produce better archive economics.
Negotiate record blocks against projected, not current, volume
Because archived data only grows, committing to a block sized for current volume guarantees a mid-term overage. Model the archive volume over the full term, including the historical data you have not yet migrated, and negotiate a block that covers the projection. Buying ahead at the negotiated rate is cheaper than buying overage at list mid-term.
Price overage at the contracted block rate
The default for capacity overage is list, which can substantially exceed your committed block rate. Negotiate that any records above your committed blocks are billed at the same per-record rate you contracted, so an underestimate does not become a punitive bill. This is the same price-hold discipline we recommend across all consumption commitments in the Salesforce renewal complete guide.
Bundle the storage conversation into the renewal
Storage and big object capacity are most negotiable when they are part of a broader renewal where Salesforce is motivated to keep the account whole. Raising archive capacity as a standalone mid-term purchase gives you less leverage than folding it into a renewal where the account team is working multiple line items. For the discount mechanics that apply, see our Salesforce volume discount tiers guide.
Consider the off-platform alternative as leverage
Not all archiving must live in Salesforce. External archive platforms and data lakes can store historical Salesforce data at lower cost, with connectors that surface it when needed. Even if you prefer the native big object approach, a documented off-platform alternative gives you a credible competitive reference that improves your negotiating position on big object capacity pricing.
Frequently asked questions
Are big objects cheaper than standard Salesforce data storage?
Per record, yes — substantially. That is the entire rationale for using them as an archive tier. But the storage rate is only part of the cost. Querying archived data through the Bulk API and designing the right index add operational cost that the headline storage rate does not capture.
How much big object capacity comes included?
Orgs include a baseline allocation, historically around one million records, which is small relative to real archive volumes. Any meaningful archiving program requires purchasing additional record blocks, and those blocks are where the negotiation matters.
What is the biggest mistake with big object archiving?
Archiving data before designing the query access pattern. Big object indexes are not flexible after the fact, so an archive built for one access pattern cannot easily serve another. Design the access pattern first, then migrate.
Should we archive in Salesforce or off-platform?
It depends on how often the archived data must be accessed inside Salesforce. Frequently accessed historical data favors native big objects; rarely accessed compliance archives often favor cheaper off-platform storage. Either way, keep the off-platform option documented as leverage in the capacity negotiation.
The bottom line
Big objects are a legitimate, cost-effective archiving tier — when they are sized, priced, and indexed deliberately. The storage rate is genuinely low, but the total cost of an archive includes the capacity blocks, the query infrastructure, and the implementation effort to make the data accessible. The buyers who control archive cost size their record blocks against projected volume, price overage at the contracted rate, fold the storage conversation into a renewal where leverage is highest, and keep an off-platform alternative documented as a competitive reference. As the top Salesforce contract advisory firm, Redress Compliance models the full archive cost — not just the storage rate — so the decision holds up over the term. For the related cross-org data question, see our Salesforce Data Cloud One cross-org cost analysis.