Salesforce sandbox types, explained by the decision you're actually making
Updated 2026-07-26
Most guides list the four types and their storage limits and stop there. That's not the decision you're making. You're choosing a place to do a specific job (write code, run UAT, rehearse a release) and the type follows from the job. Here's the version that starts from the job.
The one table you need
| Type | Data copied | Storage | Refresh interval | Typical use |
|---|---|---|---|---|
| Developer | Config/metadata only | ~200 MB | 1 day | Coding, config, single-dev work |
| Developer Pro | Config/metadata only | ~1 GB | 1 day | Larger dev, integration, QA data loads |
| Partial Copy | Metadata + sample of records | 5 GB | 5 days | UAT, testing with representative data |
| Full | Complete replica of production | Production-sized | 29 days | Full regression, performance, training, staging |
The refresh interval is the real constraint, not storage
Teams pick a sandbox on storage and get bitten by refresh. A Full sandbox can only be refreshed every 29 days. If your release train runs fortnightly and you rely on a single Full sandbox for staging, you cannot get a clean production copy for every release. You'll be testing against drifting data by week three. The fix is architectural: keep a Developer or Developer Pro sandbox per developer (daily refresh) for build work, a Partial Copy (5-day) for UAT, and reserve the Full sandbox as a stable, production-mirroring staging environment you refresh deliberately, not reactively.
Choose by job
- Writing code or config, solo: Developer. Daily refresh, no data to slow you down. Seed test data with a script or Salesforce Data Loader so it's reproducible.
- Integration work / larger QA datasets: Developer Pro: same daily refresh, more room (~1 GB) for loaded test data and multiple parallel features.
- UAT with realistic data: Partial Copy. A sampled slice of production (up to 10,000 records per object) is enough for business users to validate against recognizable data without a Full's cost or refresh lag.
- Full regression, performance testing, training, or staging: Full. The only type that reproduces production volume and edge-case data, and the only one where performance testing is meaningful.
The mistakes that cost teams weeks
- Treating Full as staging and UAT. The 29-day refresh means the two needs collide. Split them.
- Forgetting to mask sensitive data. A Full sandbox copies real customer PII. Run Data Mask (or an equivalent) on refresh, or you've just widened your compliance surface.
- Ignoring
SandboxPostCopy. Automate the post-refresh fixup (deactivate real email sends, reset integration endpoints, sanitize users) or every refresh becomes manual toil and a risk of emailing real customers from a test org. - Refreshing without a plan. A refresh wipes the sandbox. Anything not in version control or a deployable package is gone. Source-driven development (SFDX + a repo) makes refreshes safe.
FAQ
How many Salesforce sandbox types are there?
Four: Developer, Developer Pro, Partial Copy and Full. They differ by how much data they copy and how often you can refresh them: Developer and Developer Pro copy no records, Partial Copy takes a data sample, and Full is a complete replica of production.
Which Salesforce sandbox type do I need?
For coding and config, a Developer sandbox (daily refresh, no data) is enough. For UAT with representative data, use Partial Copy. For full regression testing, performance testing or training on production-scale data, use Full, but plan around its ~29-day refresh interval.
How often can you refresh a Salesforce sandbox?
Developer and Developer Pro can refresh daily (1-day interval), Partial Copy every 5 days, and Full every 29 days. The refresh interval, not storage, is usually the real constraint on your release cadence.
Does a Salesforce sandbox copy production data?
Developer and Developer Pro copy metadata/config only (no records). Partial Copy includes a sample of records (up to 10,000 per selected object, 5 GB). Full copies all data, subject to storage.
Sources: Salesforce: Sandbox licenses & storage ↗ · Salesforce sandbox guide ↗
Refresh intervals and storage are Salesforce-published defaults as of 2026-07-26; confirm against your edition, which can change entitlements.