Benefits
Why reach for SQL Simulator instead of another way to get test data.
- Catch migration problems before production does
Dry Run and Postview Image actually execute your migration or schema-change script against a real, FK-consistent sandbox and show you what happens — syntax errors, constraint violations, unexpected side effects — before that script ever touches production.
- Realistic data shapes, without a full clone
A dependency-consistent subset behaves like your real schema — foreign keys intact, related objects present — without provisioning a full copy of a database that might be gigabytes larger than what any one test actually touches.
- Safer by design
SQL Simulator has no governance layer for sensitive data — no retrieval caps, no audit trail — so it's meant to run against test/dev databases, not ones holding real sensitive data (that's what 00DB is for). Point it at a test/dev database and there's no security review or temporary production credentials to manage.
- Faster local iteration
Preview Image, Postview Image, and Dry Run each build (and, for Dry Run, immediately tear down) a working sandbox in one step, instead of hand-provisioning a database and hand-loading fixtures every time your test data needs change.
- Nothing to configure first
Get a working sandbox in minutes — there are no access policies, audit logging, or approval workflows to set up before you can start using it.
- Runs on your own infrastructure
SQL Simulator runs as containers on your own machine or infrastructure via Docker Compose — your source data and your sandbox both stay wherever you run them; nothing is uploaded to an external service to build the subset.