Salesforce sandbox storage limits are tied to your production org's data and file storage allocation, and a full copy sandbox inherits that ceiling the moment it's created. Attachments, files, big objects, and even archived activity records all count against the quota. Most teams don't notice until a refresh fails or a data load errors out mid-deployment, and by then the fix usually means an emergency cleanup under deadline pressure.
That's the wrong time to learn how storage math works in Salesforce. It's worth understanding before the next refresh cycle, not after a release gets blocked because a sandbox ran out of room.
What Actually Counts Against the Limit
Salesforce splits storage into two buckets: data storage and file storage. Data storage covers records, standard and custom objects, and big object entries. File storage covers attachments, Salesforce Files, Chatter files, and anything sitting in a content library. A full copy sandbox mirrors production's allocation at the time of creation, so if production sits at 400GB of files, the sandbox starts there too.
Custom big objects are easy to forget. Teams archive years of case history or IoT event data into big objects to keep production lean, then wonder why the sandbox copy is enormous. Big object records don't show up in the same storage dashboards admins are used to checking, so they get missed during capacity planning.
Attachments compound the problem faster than anything else. A services org with five years of signed contracts, call recordings, and PDF quotes attached to opportunities can carry hundreds of gigabytes in files alone. None of that data helps a QA engineer test a validation rule, but it all comes along for the ride in a full copy.
Why Full Copy Sandboxes Fill Up First
Partial copy and developer sandboxes have fixed, small allocations, so nobody expects to store much there. Full copy sandboxes are different: they're sized to match production, which makes them feel like they have room to spare. That assumption breaks down fast once a few refresh cycles pass.
Here's the part that catches teams off guard. Sandbox storage doesn't shrink on its own between refreshes. Every test record a QA team creates, every file uploaded during UAT, every debug log exported and attached to a case sits there accumulating. A sandbox refreshed quarterly can pick up 15-20% extra volume from test artifacts alone before the next refresh wipes it clean.
Multiply that across three or four full copy sandboxes running in parallel for different release trains, and storage stops being a background concern. It becomes a line item that shows up in Salesforce's own usage reports, sometimes triggering an email from your account executive about overage charges.
What Happens When You Hit the Ceiling
Salesforce doesn't quietly ignore an over-limit sandbox. Data loads start failing with storage errors. Batch jobs that insert records for regression tests stop mid-run. In some cases, admins can't even complete a metadata deployment because the deployment process needs headroom to stage temporary records.
The timing is rarely convenient. Storage limits tend to get hit during UAT, right when test data volume peaks and the release is closest to going live. A blocked sandbox at that stage doesn't just slow down QA, it pushes the whole release calendar back, and that delay lands on the desk of whoever owns the go-live date.
There's also a quieter cost: teams start avoiding full data loads to dodge the limit, which means test coverage gets thinner right when it should be at its widest. That's a bad trade, and it's one nobody makes on purpose. It just happens because the storage ceiling forces a shortcut.
The Fix Isn't More Storage, It's Less Data
The instinctive response is to buy additional storage from Salesforce. That works, but it's expensive and it treats the symptom. The actual problem is that full copy sandboxes are carrying production's entire history when most testing only needs a working subset that behaves like production.
This is where masking and synthetic data generation earn their keep. MaskEzee scrubs personally identifiable information out of a full copy so the org stays compliant, but it doesn't reduce volume on its own. Pair it with a tool like SproutEzee, which builds production-like data at a right-sized scale, and teams stop needing the entire seven-year attachment history just to get a realistic test environment.
I'd argue this is the single most overlooked lever in sandbox management. Admins fixate on refresh cadence and access permissions, and those matter, but storage discipline is what actually determines whether a sandbox strategy scales past two or three environments. A team running five sandboxes on bloated full copies is paying for storage they never test against.
Archiving old attachments before a refresh helps too. If a file hasn't been touched in three years and isn't part of an active test scenario, it doesn't need to travel into every sandbox refresh going forward. Some teams set a rolling cutoff, like anything older than 18 months gets excluded from the copy, and revisit that threshold once a year.
Setting a Storage Budget Per Sandbox Tier
Every sandbox tier should have a target ceiling, not just an alert threshold. A development sandbox used for unit testing rarely needs more than a few gigabytes of representative data. A full copy used for UAT and performance testing needs enough volume to be realistic without carrying every record production has ever generated.
| Sandbox Tier | Typical Use | Storage Target |
|---|---|---|
| Developer / Developer Pro | Unit testing, config work | Minimal, synthetic data only |
| Partial Copy | Feature testing, integration checks | Sampled subset, under 5GB where possible |
| Full Copy | UAT, performance, load testing | Masked and trimmed to 60-70% of production volume |
Once a budget exists, it's easy to check against actual usage after every refresh. If a full copy sandbox is consistently running at 90% of the target, that's a signal to revisit what's being archived or excluded before the next copy, not a reason to quietly buy more storage.
None of this replaces good refresh hygiene. Storage budgets and masking strategy work alongside a sensible refresh cadence, not instead of one. But storage is the constraint that shows up as a hard error message, while a stale sandbox just shows up as bad test results, so it tends to get fixed first out of necessity.
A DevOps pipeline that keeps failing on storage errors isn't a pipeline problem, it's a data problem wearing a pipeline costume. Fix the volume going into the sandbox and a surprising number of downstream deployment issues disappear along with it.
Frequently Asked Questions
How much storage does a Salesforce full copy sandbox get?
A full copy sandbox inherits the same data and file storage allocation as production at the time it's created or refreshed. If production has grown since the last refresh, the sandbox copy grows with it, which is why storage limits can sneak up between refresh cycles. There's no separate, smaller allocation for full copy sandboxes the way there is for partial copy or developer environments.
What happens if a sandbox exceeds its storage limit?
Data loads and batch record inserts start failing with storage errors, and metadata deployments can stall if the process needs temporary space to stage records. This most often surfaces during UAT or load testing, when test data volume is at its highest and the release timeline has the least room to absorb a delay. Teams sometimes work around it by deleting test records manually, which is a short-term fix that recreates the same problem within a few weeks.
Does Salesforce charge extra for sandbox storage overages?
Yes, additional storage can be purchased as an add-on, and Salesforce account teams often flag orgs running consistently over their allocation. This is usually more expensive over time than reducing the data volume going into the sandbox in the first place. Buying extra storage also doesn't fix the underlying issue of bloated, non-representative test data.
Can you free up sandbox storage without deleting test data?
Yes, by masking and right-sizing the data before it lands in the sandbox rather than cleaning it up after the fact. Tools like SproutEzee generate production-like data at a smaller, controlled scale, so teams get realistic test volume without carrying years of production history along with it. Archiving old attachments before a refresh, rather than including everything by default, also reduces file storage significantly.
How often should you check sandbox storage usage?
Check usage right after every refresh and again partway through the test cycle, since storage climbs as QA and UAT teams generate new records and files. Setting a storage budget per sandbox tier, rather than just waiting for an error message, makes it easier to catch upward trends early. Quarterly reviews of what's being archived or excluded from full copies also help keep growth predictable.