Every sandbox type has three pinch points: storage, what data it can hold, and how often you can refresh it. Knowing each one stops you from picking a sandbox that won’t fit the work.
Developer Sandbox
- Data storage: 200 MB
- File storage: 200 MB
- Data copied from production: None
- Refresh interval: 1 day
- Apex test execution: Yes
- Limitations:
- No production data — useless for testing against real volumes.
- Tiny storage; large data loads are out.
- Best for solo dev, throwaway work, single-feature branches.
Developer Pro Sandbox
- Data storage: 1 GB
- File storage: 1 GB
- Data copied from production: None
- Refresh interval: 1 day
- Apex test execution: Yes
- Limitations:
- Still no production data.
- 5× the room of a Developer sandbox, but still small for full-data testing.
- Same dev-only role, just more space.
Partial Copy Sandbox
- Data storage: 5 GB
- File storage: 5 GB
- Data copied from production: Sample defined by a sandbox template, capped at 10,000 records per object (and 100 MB per object).
- Refresh interval: 5 days
- Apex test execution: Yes
- Limitations:
- Sample size cap means it can’t host every parent record’s children — referential integrity may be patchy.
- Building the sandbox template is non-trivial; missing an object means UAT users find “missing” records.
- 5-day refresh window — not ideal if you want fresh data on every sprint.
Full Sandbox
- Data storage: Same as production.
- File storage: Same as production.
- Data copied from production: Everything — every record, every history row, every chatter post.
- Refresh interval: 29 days.
- Apex test execution: Yes.
- Limitations:
- 29-day refresh interval is the big one. A bad Full refresh you can’t redo for a month is a serious incident.
- Long refresh time — can take hours or days for very large orgs.
- Cost — every Full sandbox consumes a licence; they’re not cheap.
- PII exposure — production data lands in a non-prod environment. Data Mask or equivalent scrubbing is essentially required for GDPR/HIPAA orgs.
- No selective data refresh — it’s all or nothing.
- Slow user copy — copying users, profiles, permission sets in addition to data and metadata makes the refresh much longer than Partial.
Common limitations across all sandboxes
- All emails are suppressed by default — sandboxes won’t email real users until you change Setup → Email → Deliverability to “All emails”. Designed to stop accidental customer email blasts from UAT.
- Some integration endpoints (named credentials, remote sites) point at production after refresh — update them.
- Scheduled Apex jobs and queues carry over and may run after refresh, hitting production-like behaviour.
- OAuth connected apps may need re-authorising after refresh.
- Source-tracking is on for some sandbox types (Developer, Developer Pro since Spring ‘21) for CLI workflows.
A pragmatic rule
For most teams:
- Developer / Dev Pro — feature work and PR-level testing.
- Partial Copy — UAT with stakeholders.
- Full — final regression, performance, training.
The interview answer to “explain the limitation of each sandbox” is the storage/data/refresh table — but mentioning email suppression and the 29-day refresh trap shows real operational experience.
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.