Table of Contents
Salesforce Sandbox Types Explained
Salesforce provides four sandbox types, each with different data copy behaviour, storage limits, and refresh frequencies. Understanding what each type actually delivers is prerequisite to knowing what you are paying for — and whether you are paying for more than you need.
Developer Sandbox
Developer sandboxes are the most lightweight option: they copy only your Salesforce org's configuration (metadata) with no production data. Storage is limited to 200MB of data and 200MB of file storage. Developer sandboxes refresh daily and Salesforce includes unlimited Developer sandboxes in all paid editions — Enterprise, Unlimited, and Performance.
Developer sandboxes are appropriate for individual developer work on configuration, code, and automation — Apex, Flows, Lightning components. They are not suitable for testing with realistic data volumes or for user acceptance testing where business users need representative records to validate workflows.
Developer Pro Sandbox
Developer Pro sandboxes increase storage to 1GB of data and 1GB of file storage while retaining the metadata-only copy behaviour. Refresh frequency is once every 1 day, and Salesforce includes one Developer Pro sandbox in Enterprise Edition and 5 in Unlimited Edition.
Developer Pro sandboxes are appropriate for more complex configuration work and larger teams who need more storage than a standard Developer sandbox provides. Like Developer sandboxes, they contain no production data.
Partial Copy Sandbox
Partial Copy sandboxes copy all configuration (metadata) plus a configurable sample of production data — up to 10,000 records per selected object. Storage is limited to 5GB, and the sandbox can be refreshed every 5 days. Salesforce includes one Partial Copy sandbox in Enterprise Edition.
The Partial Copy sandbox is the most practical environment for the majority of enterprise testing scenarios: user acceptance testing, regression testing, integration testing with representative data, and training. For most organisations, a well-configured Partial Copy sandbox delivers 90% of the value of a Full sandbox at a fraction of the cost.
Full Sandbox
Full sandboxes copy the complete production org: all configuration, all data, all attachments and files. They mirror production at the point of last refresh. Storage matches your production org storage allocation. Full sandboxes can be refreshed every 29 days and are not included in Enterprise Edition — they must be purchased separately.
Full sandboxes are genuinely required in a narrow set of scenarios: performance and load testing at production data scale, compliance-driven testing where regulators require testing on production-equivalent datasets, and data migration testing where complete referential integrity across all objects is required. For general development and UAT, Full sandboxes are oversized and overpriced.
What Is Included in Your Licence
Salesforce's standard sandbox allocation by edition is a starting point that most enterprise customers expand through additional purchases. Understanding what is included as standard helps identify what you are paying for separately — and whether those additional purchases are justified.
| Sandbox Type | Enterprise Edition | Unlimited Edition | Performance Edition | Additional Sandboxes |
|---|---|---|---|---|
| Developer | Unlimited | Unlimited | Unlimited | Free (no limit) |
| Developer Pro | 1 included | 5 included | 5 included | ~$1,200–2,400/year each |
| Partial Copy | 1 included | 1 included | 1 included | ~$8,000–15,000/year each |
| Full | 0 included | 0 included | 1 included | ~$30,000–60,000/year each |
Note that Salesforce does not publish list prices for sandboxes independently — sandbox pricing is negotiated as part of the broader contract, and the ranges above reflect the market pricing we observe across client engagements. Actual pricing depends on org size, total contract value, and negotiation outcome.
The True Cost of Salesforce Sandboxes
For enterprise Salesforce customers, sandbox costs are often the second or third largest line item in the Salesforce contract after core user licences. Yet sandbox line items receive disproportionately little scrutiny at renewal — partly because they appear small relative to total licence value, and partly because no one wants to be responsible for removing infrastructure that developers depend on.
Direct Costs
A typical large enterprise Salesforce deployment might include: 3 Full sandboxes ($90,000–180,000/year), 5 Partial Copy sandboxes ($40,000–75,000/year), and 10 Developer Pro sandboxes ($12,000–24,000/year). Total annual sandbox costs of $140,000–280,000 are not unusual for large Salesforce estates — costs that can be reduced substantially through right-sizing.
Hidden Costs: Storage Overage
Full sandboxes are sized to match your production org storage allocation. As production data grows, Full sandbox storage costs increase at renewal. Organisations with large data volumes — insurers, financial services, retailers with transaction history — often find sandbox storage costs escalating faster than their licence costs. A Partial Copy sandbox sidesteps this problem entirely: the 5GB limit means storage costs are fixed and predictable regardless of production data growth.
Administrative Overhead
Full sandbox refreshes take significantly longer than Partial Copy or Developer sandbox refreshes — often 12–48 hours for large orgs compared to 1–2 hours for Partial Copy. During refresh, the sandbox is unavailable. This administrative overhead, though not a direct contract cost, represents real productivity cost that rarely appears in the sandbox ROI calculation.
Auditing Your Sandbox Utilisation
Before any Salesforce renewal negotiation involving sandboxes, conduct a sandbox utilisation audit. The audit should answer four questions for each sandbox environment:
- What is this sandbox actually used for? Document the specific testing or development activities performed in each sandbox environment.
- When was it last refreshed? Pull refresh logs from Salesforce Setup to establish actual refresh frequency. Full sandboxes refreshed less than 6 times per year are a strong signal of under-utilisation.
- Who uses it? Identify the teams and individuals who actively access each sandbox. Ghost sandboxes — environments created for projects that have ended — are common in large orgs.
- Does the sandbox type match the use case? If the sandbox is used for UAT with representative data, does it need Full production data or would 10,000 records per object (Partial Copy) suffice?
In our experience, this audit consistently surfaces 1–3 Full sandboxes that can either be eliminated or downgraded to Partial Copy without materially impacting development and testing workflows. At $30,000–60,000 per Full sandbox per year, the ROI of the audit is immediate.
Right-Sizing Your Sandbox Allocation
Right-sizing your Salesforce sandbox allocation is not about removing infrastructure teams need — it is about aligning sandbox types to actual use cases and eliminating environments that exist in the contract but not in active use.
The Substitution Framework
For each Full sandbox in your estate, apply the following decision tree:
- Does the testing workflow require production data volumes for performance or load testing? If yes, retain Full sandbox.
- Does a compliance requirement explicitly mandate testing on a production-equivalent dataset? If yes, retain Full sandbox.
- Is the sandbox used primarily for UAT, regression testing, or integration testing? If yes, evaluate Partial Copy substitution — 10,000 records per object is sufficient for most of these use cases.
- Is the sandbox used primarily by developers for configuration and code work? If yes, a Developer Pro sandbox is likely sufficient.
In most enterprise orgs, only one Full sandbox — used for periodic performance testing — can be justified commercially. Additional Full sandboxes are redundant or substitutable.
Developer Sandbox Strategy
Since Developer sandboxes are included at no cost in all enterprise editions, there is no cost benefit to limiting Developer sandbox counts. The right strategy is to ensure every developer who needs an isolated environment has their own Developer sandbox rather than sharing environments — sharing creates merge conflicts and slows delivery. Salesforce's unlimited Developer sandbox inclusion is a feature worth fully exploiting.
Negotiating Sandbox Costs at Renewal
Sandbox costs are negotiable at every Salesforce renewal. The key is entering negotiations with utilisation data that supports the commercial case for change, and knowing what levers are available.
Removing Unused Sandboxes
The most straightforward lever is eliminating sandboxes that are not in active use. If your utilisation audit identifies a Full sandbox that has not been refreshed in six months and has no active users, the commercial case for removal is unambiguous. Salesforce will typically agree to remove the line item at renewal — it is harder to justify the cost renewal when you can demonstrate non-use.
Downgrading Sandbox Types
Downgrading from Full to Partial Copy is the highest-value negotiation lever available for sandbox cost reduction. Prepare a use-case mapping that documents what each Full sandbox is used for, and present the case that Partial Copy would serve those use cases adequately. Salesforce AEs are typically willing to accept downgrades when they are clearly documented — they cannot commercially defend a Full sandbox the customer does not need.
Bundling Sandbox Credits in the Negotiation
If you are retaining sandboxes but renegotiating price, frame sandbox pricing as part of the overall contract negotiation rather than negotiating it in isolation. Salesforce AEs have more flexibility when the entire contract is on the table — a sandbox discount is easier to approve when it is presented as part of a broader package that extends the contract or expands user count.
Timing Your Sandbox Negotiation
As with all Salesforce negotiations, timing matters. Sandbox cost discussions folded into renewal negotiations in January (Salesforce fiscal year-end) or October (Q3 quarter-end) have a higher success rate than mid-cycle requests. Mid-cycle contract changes require going through Salesforce's contract amendment process, which is slower and provides less leverage than a full renewal.
For a comprehensive guide to Salesforce renewal strategy, see our Complete Guide to Salesforce Contract Negotiation, which covers the full renewal playbook including fiscal year timing, discount structures, and competitive leverage tactics.