Salesforce Sandbox Types Compared: Developer, Pro, Partial, Full

Salesforce has four sandbox types. Developer and Developer Pro sandboxes copy only metadata and can be refreshed daily; they differ in storage (200 MB vs 1 GB). A Partial Copy sandbox adds a template-defined sample of production data and refreshes every 5 days. A Full sandbox copies all data and metadata but can only be refreshed every 29 days.

The rest of this post covers the details that actually drive the decision: what each type copies, how much it holds, which editions include it, and which one fits dev, QA, UAT, training or staging. Every number below comes from Salesforce's Sandbox Licenses and Storage Limits by Type documentation.

How do the Salesforce sandbox types compare?

Here's the whole comparison on one screen. The main difference between the types is what gets copied. Storage and refresh interval follow from that.

	Developer	Developer Pro	Partial Copy	Full
What's copied	Metadata only	Metadata only	Metadata + sample data	Metadata + all data
Data storage	200 MB (400 MB with upgrade)	1 GB (2 GB with upgrade)	5 GB	Same as production
File storage	200 MB	1 GB	Same as production	Same as production
Refresh interval	1 day	1 day	5 days	29 days
Sandbox templates	Not available	Not available	Required	Available (optional)
Typical use	Individual development, unit testing	Larger-data dev, integration testing, training	QA, UAT, integration testing, training	Performance/load testing, staging, final UAT

The refresh interval is counted from when you request the creation or refresh, not from when the copy finishes. If you want the full rules on that timer, see how often you can refresh a Salesforce sandbox.

Which sandboxes come with each Salesforce edition?

Which sandboxes you get depends on your edition, and you can buy more. Here is what's included out of the box:

Sandbox type	Professional	Enterprise	Unlimited	Performance
Developer	10	25	100	100
Developer Pro	—	—	5	5
Partial Copy	Not available	1	1	1
Full	Not available	—	1	1

A dash means "not included, but purchasable". You can buy extra Developer Pro sandboxes for any edition, and Partial Copy and Full sandboxes for Enterprise, Unlimited and Performance. Developer sandboxes can't be bought on their own. They come bundled with add-ons: 5 with a Developer Pro add-on, 10 with a Partial Copy add-on and 15 with a Full add-on.

Sandbox licenses are also hierarchical. A Full license can create any type, a Partial Copy license can create Partial Copy, Developer Pro or Developer sandboxes, and so on down. That lets you spend an unused higher-tier license on a lower-tier sandbox when you need to.

What is a Developer sandbox for?

A Developer sandbox is for one developer (or one feature) building and testing in isolation. It copies your production configuration but no records, so it's quick to create and cheap to throw away. With 200 MB of data storage, it holds test data and very little else. That's a limit you'll hit quickly if you try to load realistic volumes. The daily refresh makes it the natural "reset to production metadata" environment.

What is a Developer Pro sandbox for?

A Developer Pro sandbox is a Developer sandbox with five times the storage: 1 GB of data and 1 GB of files. Salesforce positions it for heavier development and QA work, integration testing and user training. It's still metadata-only, so you bring your own data. The extra headroom matters once you're loading a few hundred thousand records or testing file-heavy features. Both Developer and Developer Pro can be upgraded (to 400 MB and 2 GB of data storage respectively).

What is a Partial Copy sandbox for?

A Partial Copy sandbox is Salesforce's QA/UAT environment. It copies all metadata plus a sample of production data defined by a sandbox template. According to Salesforce's Partial Copy guidance, the sample can include standard and custom object records and attachments up to 5 GB, with a maximum of 10,000 records per selected object. The template is mandatory: without one, the Create button doesn't appear.

Two catches to plan for:

• The template picks objects, not specific records. The editor adds required related objects automatically (select a detail object and its master comes along), but which records land in the sample isn't something you hand-pick.
• Portal and community users aren't copied. Records created or modified by external users can show access errors in the sandbox.

What is a Full sandbox for?

A Full sandbox is a replica of production, with all records, attachments and metadata. It's the only type Salesforce says supports performance testing, load testing and staging. When you create one, you also decide whether to include field history tracking and Chatter activity. Field history is off by default, and Salesforce warns that Chatter data can add significant copy time. Templates are optional here. Salesforce actually recommends applying one so the sandbox holds only the records you need.

The trade-offs are cost and the 29-day refresh interval, which Salesforce itself says makes Full sandboxes hard to use for development. Also remember that a Full sandbox copies production PII as-is. If that's a concern, masking PII in your sandboxes belongs in your post-refresh routine.

Where do scratch orgs fit?

A scratch org is not a sandbox. It's a disposable, source-driven org created from a Dev Hub, described in the Salesforce DX Developer Guide. It starts empty: no copy of production metadata or data. You shape it with a definition file and push source into it. Scratch orgs last 1 to 30 days (7 by default) and can't be restored after they expire. Dev Hub is available in Developer, Enterprise, Unlimited and Performance editions, and your Dev Hub edition sets how many you can create. Salesforce explicitly says not to put personal data in them.

Scratch orgs suit package development and CI pipelines where every run should start from a known, clean state. They're a poor fit when you need your org's real, accumulated configuration.

Which sandbox type should you use?

Pick based on the job, not on the most powerful license you own:

If you need to…	Use
Build a feature or fix a bug in isolation	Developer sandbox
Develop against larger data volumes or integrations	Developer Pro sandbox
Run CI tests or build a package from source	Scratch org
Run QA or UAT on realistic, related data	Partial Copy sandbox
Train users on a production-like environment	Developer Pro or Partial Copy
Load-test, performance-test or stage a release	Full sandbox
Reproduce a production bug that depends on specific records	Full sandbox, or a lighter sandbox plus a targeted data copy

Most teams end up with a pipeline that looks like Developer (or scratch) → Partial Copy for QA/UAT → Full for staging. That's a sensible default. The friction shows up at the edges: Developer sandboxes that are too empty to test meaningfully, and a Full sandbox you can only refresh once a month.

Can you get production-like data without a Full sandbox?

Yes. The common pattern is a lighter sandbox plus a data-movement step. The seven Full Copy alternatives post covers the options, from synthetic data to Data Loader scripts. Syntharil is one of them. It copies a filtered, masked subset of production into a sandbox you already own, on demand, with per-object SOQL filters and incremental delta refreshes. It deliberately excludes Chatter feeds, User records and field history, so if you need those cloned, a Full sandbox remains the right tool. The Full Copy sandbox alternative comparison lays out where each approach wins.

Bottom line

Match the sandbox to the work. Use Developer and Developer Pro for building, Partial Copy for QA, UAT and training, and Full only for performance testing and staging, where you really need all of production. Keep an eye on storage limits in the smaller sandboxes, because they fill up fast. If the 5-day or 29-day refresh interval is what's slowing you down, change how data gets into your sandboxes rather than buying a bigger license.