Is a Sandbox a Reliable Place to Test Performance?

Sandboxes are a safe place to test API calls, workflows, and destructive actions like deletes before they touch production data — but whether they're a reliable stand-in for performance testing depends on which cloud environment your account runs in.

Standard production accounts

Your sandbox runs on a dedicated database cluster using instances that are half the size of the instances behind your primary account's cluster. Because of this size difference, anything that performs well in your sandbox will run at least as well on your primary account. In other words, your sandbox acts as a "worst case" test bed — if a process is fast enough there, it will be fast enough in production too.

HIPAA, private cloud, and government cloud accounts

For accounts on HIPAA, private cloud, or government cloud infrastructure, the sandbox resides on the same infrastructure as the primary account. In these environments, the performance of a specific process in your sandbox should closely match its performance in production, since there's no difference in underlying hardware or capacity between the two.

What sandbox testing won't catch: concurrency issues

Regardless of environment, one category of problem that sandbox testing is not well-suited to catch is concurrency issues. Sandboxes typically don't have every process running at the same time the way a live production account does — including manual data entry from multiple users. Because of that lighter, less simultaneous load, issues like lock blocking or deadlocks may not surface during sandbox testing even though they can occur once the same processes run concurrently in production.

If your use case involves many simultaneous writes to the same records or tables (for example, several users or automations updating the same data at once), plan for additional concurrency testing beyond what your sandbox can reveal, or monitor closely after promoting changes to production.