Salesforce load testing on a sandbox with a few thousand records tells you almost nothing about how the org behaves under real volume. Query plans, index selectivity, sharing rule recalculation, and flow bulkification all change shape once a table crosses the row counts where Salesforce's optimizer switches strategy. A test suite that passes cleanly on 5,000 accounts can fall over at 500,000, and most teams only find out after go-live.
This isn't a niche concern for companies running massive orgs. Any team with 500 to 5,000 employees running Sales or Service Cloud at scale has data volume thresholds somewhere in their object model, usually on Account, Contact, Case, or a custom object tied to a high-velocity process. If your load tests run against a sandbox that doesn't reflect that volume, you're testing a different application than the one your users will hit.
Why Sandbox Data Volume Skews Load Test Results
Salesforce's query optimizer picks an index or falls back to a full table scan based on selectivity, and selectivity is a function of row count. A SOQL query that returns in 200 milliseconds against 10,000 records can take several seconds against 2 million, even with the exact same index in place. Below roughly 200,000 rows on standard objects, the optimizer sometimes skips indexes entirely because a full scan is cheap enough not to matter.
That threshold effect is the whole problem. Teams run their load tests, everything looks fast, and they conclude the org is ready. What they've actually measured is how fast queries run when the optimizer isn't under any real pressure. The moment production data crosses that threshold, query plans shift and previously invisible bottlenecks show up in front of live users.
Governor limits behave the same way. A trigger that queries related records inside a loop might stay under the SOQL limit with ten child records per parent. Give it two hundred child records, which is common on Case or Opportunity Line Item in a busy service org, and the same trigger starts throwing limit exceptions. Sparse sandbox data simply never exercises that path.
What Breaks First When Data Scales
Sharing rule recalculation is usually the first casualty. Every time role hierarchy changes, or a sharing rule is added, or a large batch of records gets reparented, Salesforce recalculates access at the row level. On a sandbox with a few hundred accounts this finishes in seconds. On a production org with millions of accounts and a deep role hierarchy, the same recalculation can run for hours and lock other operations behind it.
Roll-up summary fields follow a similar pattern. A roll-up on Opportunity that sums a custom field across ten child line items recalculates instantly. The same roll-up across a parent with 50,000 children, which happens more often than most admins expect on long-lived Case or Contract records, can push past processing limits and silently fail to update.
Flows and batch Apex are the third pressure point. Bulkification bugs hide in low-volume testing because a loop that runs three times looks identical to a loop that runs three thousand times, right up until it doesn't. Automation that was written and tested against a handful of sample records tends to assume single-record context, and that assumption breaks the first time a real data load bulk-inserts or bulk-updates thousands of rows at once.
| Object | Common trigger point | Row count where it typically bites |
|---|---|---|
| Account / Contact | Sharing recalculation, index selectivity | 200K+ rows |
| Case | Trigger loops, SOQL in automation | 50K+ related child records |
| Opportunity | Roll-up summary limits | 10K+ line items per parent set |
| Custom high-volume object | Batch Apex governor limits | Varies, test at 2-3x expected peak |
The Trap of Partial and Developer Sandboxes for Performance Testing
Developer and Developer Pro sandboxes cap storage at 200MB to 1GB, which forces a tiny data footprint no matter what you do. Partial copy sandboxes are better but still sample a fraction of production records, and the sampling logic doesn't preserve the skew and clustering patterns that actually cause performance problems. A partial copy might grab 10,000 accounts evenly, when the real issue in production is one account with 40,000 related contacts.
Full copy sandboxes solve the volume problem but introduce two new ones: refresh cadence and cost. Most orgs refresh a full copy every 30 to 90 days, so by the time you're load testing, the data is already stale relative to current production growth. Full copy licenses are also expensive to run continuously, which pushes teams toward doing performance testing rarely instead of on every release.
None of this is really about which sandbox type is best. It's about the fact that every standard option forces a trade-off between volume, freshness, and cost, and load testing needs all three at once.
Building Production-Like Volume Without a Full Copy Refresh
This is the gap SproutEzee was built to close. Instead of waiting on a full copy refresh cycle, it generates synthetic data that mirrors production's volume, distribution, and skew inside a lower-tier sandbox. You get an Account object with the same clustering pattern as production, a Case object with the same backlog shape, and Opportunity records with the same line-item density, without copying a single real customer record.
The distinction matters because volume alone isn't enough. A test dataset with a million evenly distributed rows behaves nothing like production, where 5% of accounts often hold 60% of the related records. Synthetic generation that respects that skew catches the sharing recalculation and roll-up limit issues that a uniform dataset masks completely.
Because the data is generated rather than copied, it also sidesteps the masking step that full copy sandboxes require before any load testing can start under GDPR or CCPA obligations. Teams running MaskEzee on a full copy still have to run and validate that masking job before performance testing begins; a synthetic dataset removes that dependency entirely and lets performance testing run as a standing part of the pipeline rather than a quarterly event.
A Practical Load Testing Checklist Before Go-Live
Before signing off on any release that touches a high-volume object, run through this list. It's short on purpose, because the point is catching the two or three things that actually break, not generating a compliance document nobody reads.
- Confirm test data volume matches production within 2-3x on every object touched by the release, not just the primary one.
- Check that data skew and clustering are represented, not just row count, especially on Account, Case, and any parent-child roll-up relationship.
- Run governor limit checks against bulk operations of 200+ records, since that's the batch size Salesforce uses internally for triggers and flows.
- Time sharing rule recalculation separately from the main test, since it can run asynchronously and mask its own delay.
- Re-run the same load test after any role hierarchy or sharing rule change, even if the release itself didn't touch automation.
Teams that skip the skew check are the ones who get paged at 2am three weeks after a clean release, once the account that was seeded with 40,000 test contacts finally exists in production with real customer data behind it. I've seen this exact failure mode more than once, and it's always traced back to a load test that measured the wrong shape of data.
Making Load Testing Part of the Pipeline, Not a Pre-Launch Scramble
The teams that handle this well don't treat load testing as a one-off gate before a major release. They build it into the regular sandbox refresh and CI/CD cycle, so every deployment gets checked against production-like volume as a matter of course rather than an exception reserved for the biggest launches.
That only works if generating realistic data doesn't require a multi-day full copy refresh every time. Pairing a DevOps pipeline with a synthetic data tool like SproutEzee turns performance testing from an occasional fire drill into a step that runs automatically on every sandbox used for pre-production validation. The org you test against starts looking like the org your users actually work in, and the surprises move from production incident reports to caught-in-CI tickets, which is exactly where they belong.
Frequently Asked Questions
Why does Salesforce load testing pass in a sandbox but fail in production?
Sandbox data volume is usually far smaller than production, which means the query optimizer, sharing rule recalculation, and roll-up summary fields never hit the thresholds where performance actually degrades. A trigger or flow that looks fine against a few hundred records can throw governor limit exceptions against tens of thousands. The fix is testing against data that matches production volume and distribution, not just record type coverage.
How much data do I need in a sandbox for accurate load testing?
Aim for 2-3x your expected peak production volume on every object the release touches, not just the primary one. Row count alone isn't enough though; the data also needs to match production's skew, meaning some parent records should have disproportionately more child records than others. A uniform distribution hides the exact bugs that real, clustered customer data exposes.
Can a partial copy sandbox be used for performance testing?
Partial copy sandboxes sample a fraction of production records, but standard sampling logic tends to flatten out the clustering and skew that cause real performance problems. They're fine for functional QA but generally unreliable for load testing unless the sample is specifically built to preserve data distribution. Full copy or synthetic data generation gives more trustworthy results for this purpose.
What breaks first when Salesforce data volume scales up?
Sharing rule recalculation is usually the first bottleneck, since it runs at the row level across the entire org and can take hours on large data sets with deep role hierarchies. Roll-up summary fields and bulk automation, including triggers and flows, follow closely behind once parent records accumulate large numbers of children. All three of these are effectively invisible in low-volume sandbox testing.
How does synthetic data help with Salesforce load testing?
Synthetic data generation, like what SproutEzee produces, creates records that mirror production's volume and skew without copying real customer data. This avoids the refresh delays and masking steps that come with full copy sandboxes, so performance testing can run on a regular schedule rather than only before major releases. It also lets teams reproduce specific high-volume scenarios, like one account with tens of thousands of related contacts, on demand.