Salesforce data storage is sold as a per-org base allowance plus a per-user increment, split across data storage (the structured-record allocation) and file storage (the attachment-and-content allocation). The Admodum read on the allocation table, the Big Objects platform, the overage list-step, the archive architecture, and the buyer-side rationalisation discipline.
Salesforce data storage is sold as a per-org base allowance plus a per-user increment. The Enterprise and Unlimited Edition production org ships with a published base allocation of ten gigabytes of data storage and a richer base allocation of file storage. Above the base, the allocation grows with the named-user count: each additional user adds a published per-user increment that varies by edition tier.
The Essentials and Professional editions ship with smaller base allocations. The Performance and Unlimited editions ship with richer per-user increments. The allocation table reads against the wider Sales Cloud editions and Service Cloud editions spokes. The realised allocation is therefore a function of the contracted edition mix and the deployed named-user inventory, not of the standalone storage purchase.
The allocation is split into two pools. The data-storage pool holds the structured-record allocation for the standard and custom objects (Account, Contact, Opportunity, Case, custom-object rows). The file-storage pool holds the unstructured-content allocation for Content Documents, Files, Attachments, Knowledge Articles with attached files, and Email-with-attachment records. The two pools have different per-edition allocation profiles and different per-gigabyte list-step prices.
Each row in a standard or custom object consumes a fixed two kilobytes of data storage regardless of the actual field-value footprint. The architectural implication is that record-count growth, not field-value growth, is the principal driver of data-storage consumption. An object with a few populated fields consumes the same two kilobytes as an object with hundreds of populated fields. The architectural read aligns the record-count growth against the allocation rather than counting bytes.
Big Objects are the purpose-built archive object class for high-volume, low-frequency-access data. The Big Object schema holds billions of rows at a published list step that sits materially below the standard data-storage list step. The architecture uses an indexed denormalised schema with limited query capability; the trade is high-volume capacity in exchange for restricted SOQL access patterns and no triggers, workflow, or process automation against the rows.
The Big Object surface is the principal architectural lever for retiring historical record volumes from the standard data-storage pool. The architectural read is the historic-record archive position: which standard or custom-object records still need transactional access, which have aged into reference-only access, and which can move into a Big Object archive against an indexed query path. The discipline materially reshapes the data-storage commitment without losing the historic record.
Salesforce publishes a per-gigabyte list step for incremental data storage and a separate per-gigabyte list step for incremental file storage. The realised closing band is contract-by-contract; the realised rate reflects the contracted edition mix, the deployed named-user inventory, and the wider commercial position. The list-step on incremental storage carries a published premium against the bundled per-user increment, which means the storage commitment is materially more economical when planned at the edition-and-user-count level rather than purchased incrementally at year-end.
The buyer-side archive architecture reads the standard-object and custom-object growth-rate forecast against the renewal anchor and identifies the candidate-record cohort for retirement to a Big Object archive or to an external archive surface (Data Cloud, an external lake, or a third-party archive product). The architectural read targets the data-storage pool reduction inside the contracted base and per-user-increment allocation rather than the incremental purchase.
The data-storage renewal cycle aligns with the wider Salesforce master subscription agreement. The renewal-cycle artefact reads the deployed data-storage and file-storage consumption against the per-edition allocation table, the consumption growth-rate forecast against the renewal anchor, the Big Objects archive position against the candidate-record cohort, and the per-gigabyte list-step the publisher carries against the realised closing band drawn from the firm's Benchmarking library on the platform cluster.
The renewal-evidence pack carries four artefacts on the storage surface. The data-storage and file-storage consumption against the per-edition allocation table. The consumption growth-rate against the contracted edition mix and the deployed named-user inventory. The Big Objects archive position and the candidate-record cohort. The renewal posture against the publisher's per-gigabyte list-step. The pack is the closing position transmitted to the publisher inside the Renewal Programme cycle, countersigned by a second partner.
The commitment-design discipline reads four artefacts at the buyer-side commercial level: the deployed data-storage and file-storage consumption against the per-edition allocation; the record-archive position on the Big Objects surface against the candidate-record cohort; the consumption growth-rate forecast against the renewal anchor on the production-org footprint; the renewal-cycle posture against the publisher's per-gigabyte list-step on incremental storage.
The senior-advisor read produces the renewal evidence pack and the closing-band benchmark drawn from the firm's Benchmarking library on the platform cluster. The discipline aligns the storage commitment to the rationalised allocation against the deployed and forecast record inventory rather than to the incremental-purchase position at year-end. The wider org strategy spoke reads the cross-org duplication position on data and file storage allocation.
The single-org versus multi-org decision that determines the duplicated storage allocation.
The sandbox-tier storage profile that shapes the lower-environment data footprint.
The unified-profile surface that can carry archive-storage workloads off the platform.
A senior Admodum Salesforce advisor will read your data-storage and file-storage consumption, your per-edition allocation, your Big Objects archive position and your renewal anchor on a private call. Active renewal moments route to Renewal Programme.
Vendor Intelligence Monthly
One monthly briefing on Salesforce pricing moves, contract precedents and negotiation windows. Written by the advisors who run the engagements. No marketing list.
Subscribe to the briefing