Salesforce offers four sandbox types, ordered from cheapest/smallest to most expensive/largest:
- Developer Sandbox
- Developer Pro Sandbox
- Partial Copy Sandbox
- Full Sandbox
All four copy your production org’s metadata (objects, fields, code, layouts, automation). They differ in how much data they include and how big the storage limit is.
The full picture
| Developer | Developer Pro | Partial Copy | Full | |
|---|---|---|---|---|
| Metadata copy | Yes | Yes | Yes | Yes |
| Data copy | None | None | Sample (per template, capped at 10,000 records per object) | All production data |
| Data storage | 200 MB | 1 GB | 5 GB | Same as production |
| File storage | 200 MB | 1 GB | 5 GB | Same as production |
| Refresh interval | 1 day | 1 day | 5 days | 29 days |
| Typical cost (relative) | Free / included | Lower | Mid | Highest |
| Best for | Solo dev work | Bigger solo dev | UAT, realistic sample data, training | Staging, performance testing, full integration testing, training with real volumes |
Developer Sandbox
The most common type. Empty of data; great for solo developer work. Refresh daily, so you can throw it away and start over without scheduling pain.
Use when: You’re building Apex / LWC / configuration solo and don’t need production-like data. Just write your test data or load a small CSV.
Developer Pro Sandbox
Identical in concept to Developer, but five times the storage. Useful when you want to keep multiple work-in-progress feature branches in flight without running out of room.
Use when: Solo dev work, but you’ve outgrown 200 MB — maybe you’re caching a meaningful sample for repeatable testing.
Partial Copy Sandbox
Metadata plus a sample of production data, defined by a sandbox template you build. The template lists which objects to seed; Salesforce copies up to 10,000 records per object. Great for UAT where users want recognisable data, but you don’t need every row.
Use when: User acceptance testing, integration testing, training new admins on realistic-looking data, regression testing.
Full Sandbox
A complete copy of production — metadata plus all records, plus history, plus chatter feeds, plus everything. It’s effectively a clone.
The trade-off is the 29-day refresh interval: once you’ve refreshed, you have to wait nearly a month before you can refresh again. Plan accordingly.
Use when: Pre-production staging, performance testing at real data volumes, full end-to-end UAT, disaster-recovery rehearsals, full integration testing with downstream systems.
Picking the right type
A typical mid-size company sandbox setup:
- 2–3 Developer sandboxes — one per active developer.
- 1 Developer Pro — shared integration / SIT environment.
- 1 Partial Copy — UAT with sample data.
- 1 Full sandbox — staging / pre-prod / training.
That’s roughly the spread the Enterprise Edition’s sandbox licences cover by default; bigger orgs buy more.
Refresh interval, explained
The refresh interval is the minimum time between refreshes of the same sandbox. So a Full sandbox refreshed today can’t be refreshed again for 29 days. The interval exists because Full sandbox refreshes are expensive operations for Salesforce to run — they copy gigabytes of data.
Data masking
When real production data lands in a non-production sandbox, you have a privacy problem. Salesforce ships Data Mask as a managed package — it scrambles PII (emails, names, addresses, phones) in a refreshed sandbox so testers can’t see real customer data. For Full / Partial sandboxes that hold production data, Data Mask is essentially mandatory under GDPR/HIPAA-type regimes.
Verified against: Salesforce Help — Sandbox Types and Templates, Salesforce DX Developer Guide, Metadata API Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.