Salesforce offers four sandbox types and most teams default to whichever one they can get approved, rather than whichever one actually fits the work. The result is developers blocked on storage limits in Developer sandboxes, QA teams testing against data shapes that do not resemble production, and UAT sign-offs from full sandboxes that take three days to refresh before anyone can use them. Understanding the practical difference between a Salesforce full sandbox vs partial sandbox vs developer sandbox is not a licensing question — it is a delivery question. The wrong sandbox type adds friction to every release you run.
The Four Sandbox Types: What Each One Actually Copies
Salesforce defines sandbox types by two axes: what they copy (metadata only, or metadata plus data), and how much storage they include. The storage limit is the more consequential constraint in practice.
| Type | Metadata | Data | Storage | Refresh Limit |
|---|---|---|---|---|
| Developer | All | None | 200 MB | 1 day |
| Developer Pro | All | None | 1 GB | 1 day |
| Partial Copy | All | Template-defined subset | 5 GB | 5 days |
| Full | All | All (up to org limit) | Same as production | 29 days |
The refresh limit column matters more than it looks. A full sandbox can only be refreshed once every 29 days — meaning if your UAT environment gets corrupted, you are either waiting nearly a month or requesting an exception from Salesforce support. Partial sandboxes are capped at one refresh every five days, which is workable for a regular sprint cadence. Developer sandboxes refresh daily, which is why they are the right choice for active feature development where you want a clean slate between sprints.
Developer Sandbox: Right for Isolated Feature Work, Wrong for Integration Testing
Developer sandboxes are designed for individual developers working on isolated features. They copy your complete production metadata — every object, field, flow, Apex class, permission set, and configuration — so developers are always building against the current schema. What they do not copy is any data. You start with an empty org and create whatever test records your work requires.
The 200 MB data storage limit is the binding constraint. For most feature development this is not an issue — you can create a few hundred records of any object without approaching that limit. Where it becomes a problem is when developers need to test automation that operates on bulk data, or when they need to seed realistic volumes to validate SOQL query performance. A developer sandbox will never tell you whether your query behaves correctly at 500,000 records — it will only tell you whether it runs at all.
The correct pattern for developer sandboxes is one per developer. This eliminates the coordination overhead of shared environments — no "who changed this record" debugging, no conflicts between partially built features, no blocked deployments because someone's work-in-progress broke a shared environment. Developer sandboxes are cheap enough that providing every developer their own is almost always the right call.
Developer Pro Sandbox: The Right Upgrade for Automated Testing
Developer Pro sandboxes are frequently overlooked because teams tend to jump straight from Developer to Full when they need more space. The 1 GB data storage limit is the only meaningful difference from a standard Developer sandbox — same metadata copy, same daily refresh cadence, higher price point but significantly lower than a Partial or Full license.
The use case for Developer Pro is automated test suites that require a meaningful data set to run against. If your CI/CD pipeline deploys to a sandbox and runs your Apex test suite after every deployment, a Developer Pro gives your tests enough data headroom to execute realistic assertions without the cost and refresh restrictions of a Partial sandbox. For teams running Salesforce CI/CD pipelines, a dedicated Developer Pro sandbox as the CI target is a practical and cost-effective configuration.
Partial Sandbox: The Workhorse of Integration and Sprint Testing
A partial sandbox copies all production metadata plus a configurable subset of production data defined by sandbox templates. Templates let you specify which objects to include, optional filter criteria, and a maximum record count per object. You might include all Account records created in the last 12 months, all open Cases, all products from your active price book, and 10,000 Contact records sampled randomly. What you get is an environment with realistic data shapes and relationships without the storage footprint of a full data copy.
The 5 GB storage limit is enough for almost all integration testing and sprint UAT work. The five-day minimum between refreshes fits neatly into a standard two-week sprint: refresh at the start of a sprint, run integration testing and UAT mid-sprint, refresh again at the start of the next sprint if needed.
The most common misconfiguration with partial sandboxes is poorly designed templates. Teams often either include too little data — making the environment feel artificial and missing edge cases — or include too much, approaching the 5 GB limit and slowing down the refresh. A well-designed partial sandbox template should include:
- All parent records for any object your feature touches
- A representative sample of child records — not all of them, but enough to test relationship-dependent logic
- All lookup table data (price books, record types, custom metadata)
- Enough volume to trigger bulk processing paths in your automations
What partial sandboxes are not suitable for: performance testing at production data volumes, load testing integrations, or final go-live readiness validation. Those workloads require a full sandbox.
Sandbox management that actually scales
SproutEzee handles sandbox creation, refresh scheduling, and data seeding — so your environments are ready when your team needs them, not three days later.
See SproutEzee →Full Sandbox: Reserved for Performance Testing and Pre-Production UAT
A full sandbox is the only environment where you can validate how your Salesforce org will actually behave under production conditions. It copies all production data — every record, every file, every attachment — and it has the same storage ceiling as your production org. For a large org this refresh can take two to four days. That is not a bug; it is the cost of having a complete production replica.
The 29-day refresh minimum means you cannot treat a full sandbox the way you treat a developer or partial sandbox — it is a long-lived environment, not a disposable one. Protect it accordingly: establish clear access controls, do not allow developers to make ad-hoc data changes that would corrupt the environment, and plan your refresh windows around release cycles rather than individual sprints.
Full sandboxes are the right environment for three specific activities:
- Performance and load testing — querying 50 million records behaves differently from querying 50,000. Governor limit interactions, SOQL performance, and integration throughput can only be validated at production volume.
- Final pre-production UAT — sign-off that the feature behaves correctly against real data shapes, including edge cases that only exist in production records.
- Integration stress testing — verifying that your middleware can handle the data volumes, error rates, and record relationships that actually exist in your org.
If your team is using a full sandbox for daily development work, you are using the most expensive and most restricted environment for the workload that should be handled by developer sandboxes. That is a common pattern in teams that have not built out a proper environment strategy, and it is one of the root causes of the "sandbox refresh taking too long" complaint.
The Data Masking Problem Across All Sandbox Types
Partial and full sandboxes copy real production records. That means real customer names, email addresses, phone numbers, and whatever other personal data exists in your org lands in environments with wider access than production. Developers access sandboxes from personal laptops, from home networks, from devices that do not carry the endpoint management controls your production access requires. The GDPR and HIPAA position on this is unambiguous: personal data in a sandbox is still personal data, and inadequate technical safeguards in that environment is a compliance failure regardless of whether the data is actively misused.
The standard approach — and the only defensible approach under a data protection framework — is to apply masking to sandboxes at or immediately after the point of refresh. This means customer-facing PII fields are replaced with realistic but synthetic values: names become random name strings, email addresses become anonymised addresses, phone numbers become generated numbers in the correct format. The data shape and relationships are preserved; the actual personal information is not. Tools like MaskEzee integrate directly with Salesforce to apply this masking as part of the sandbox lifecycle rather than as a manual post-refresh task that someone remembers to run inconsistently.
Building an Environment Strategy That Matches Your Team
A practical environment strategy for a team of five to twenty developers running regular sprint releases typically looks like this:
- Per-developer Developer sandboxes — one each, refreshed at the start of each sprint, used for feature build and unit testing
- Shared Developer Pro sandbox — used by CI/CD pipeline for automated test runs on every deployment
- Partial sandbox — used for integration testing and sprint UAT, refreshed at sprint boundaries, masked on refresh
- Full sandbox — used for performance testing and final pre-release UAT, refreshed once per major release cycle
This hierarchy means each workload goes to the environment type that is correctly sized for it. Developer sandboxes absorb the high-velocity, daily refresh cycle. The full sandbox sits as a stable, long-lived replica used only for the most critical validation activities. The partial sandbox in the middle handles the sprint-level integration work that sits between individual development and final go-live validation.
The most common deviation from this pattern — and the one that causes the most delivery friction — is teams collapsing all testing into a single shared environment. One environment for development, integration, UAT, and performance testing produces constant conflicts, unpredictable state, and the kind of "it worked yesterday" debugging sessions that consume significant engineering time. Environment isolation is one of the foundational practices of reliable Salesforce delivery, and the cost of getting the sandbox mix right is almost always recovered in the first few releases.
Frequently Asked Questions
What is the difference between a full sandbox and a partial sandbox in Salesforce?
A full sandbox copies all of your production metadata and all of your production data — every record, every file, every attachment — up to the storage limit of your org. A partial sandbox copies all metadata but only a configurable subset of data, defined by sandbox templates that specify which objects to include and how many records. The practical difference: a full sandbox is an exact replica of production suitable for load testing and UAT that requires production-representative data volumes. A partial sandbox is suitable for integration testing and UAT where you need representative data shapes but not complete volumes.
How long does a Salesforce full sandbox refresh take?
Full sandbox refreshes can take anywhere from a few hours to several days depending on your org's total data volume, the number of files and attachments, and current Salesforce infrastructure load. Orgs with tens of millions of records and large file stores regularly see refresh times of two to four days. This is one of the strongest arguments for maintaining a partial sandbox for development and integration work alongside your full sandbox for UAT — you cannot afford your primary test environment being unavailable for days while a refresh completes.
Can you have multiple sandboxes of the same type?
The number of sandboxes available depends on your Salesforce edition and any additional sandbox licenses purchased. Enterprise Edition includes one partial sandbox and one developer sandbox per org by default. Additional sandboxes of any type can be purchased. Full sandboxes are the most expensive type and most organisations have one, occasionally two. Developer Pro and Developer sandboxes are significantly cheaper and are commonly purchased in batches for individual developer use.
What is a Developer Pro sandbox and when should you use it?
A Developer Pro sandbox includes all production metadata plus up to 1 GB of data storage, compared to 200 MB for a standard Developer sandbox. Use Developer Pro sandboxes when individual developers need to work with more than trivially small data volumes, or when you are running automated test suites that require a meaningful data set. The 1 GB limit is still well short of what you need for full integration testing, but it is enough to run realistic unit and functional tests without hitting storage errors.
Does personal data from production end up in sandboxes automatically?
Yes — both full and partial sandboxes copy real production records, which means real customer names, email addresses, phone numbers, and other personal data lands in your sandbox environment. This is a significant GDPR and HIPAA compliance risk. Any org subject to data protection regulations must apply data masking to sandbox environments either during or immediately after the refresh process. Running un-masked sandboxes with real personal data is a compliance breach regardless of whether that data is deliberately accessed.