Analytics sandbox cost: why your non production data stack costs as much as production

Quick answer

Non production data environments often cost 40 to 70 percent of production while delivering a fraction of the value, because they are cloned from production configuration and then left running. The three fixes are schedule based shutdown outside working hours, which saves about 70 percent of compute on a 50 hour week, sampled datasets instead of full production copies, which cuts both storage and scan cost by 90 percent or more, and smaller compute sizes, since a sandbox almost never needs production scale. Applied together these typically reclaim 60 to 80 percent of non production data platform spend.

Non production environments get created in a hurry, usually by copying the production Terraform module and changing a name prefix. That copy inherits production's warehouse size, node count, retention settings, and schedule, none of which a sandbox needs. Then it runs continuously, because nobody owns shutting it down and nobody is watching its line on the bill.

What a copied environment costs

Component	Production	Cloned sandbox	Right sized sandbox
Warehouse	Large, 12 h/day	Large, 24 h/day idle	X-Small, 50 h/week
Warehouse cost/month	~$8,640	~$17,280	~$650
Data volume	40 TB	40 TB full copy	400 GB sample
Storage/month	~$920	~$920	~$9
Pipeline runs	Hourly	Hourly	On demand

The cloned sandbox costs more than production, because production suspends between business hours while the sandbox was never configured to. This is not a hypothetical: a warehouse left un suspended is the most common single finding in non production cost reviews, and it costs full rate for 24 hours a day of nothing.

Fix one: schedule based shutdown

A working week is roughly 50 hours out of 168, about 30 percent. Shutting non production compute outside working hours therefore saves around 70 percent immediately. Implement it as a scheduled job that suspends warehouses, terminates clusters, and scales instance groups to zero at 7pm and restores them at 8am on weekdays. Combine with aggressiveauto suspend so even within working hours the compute sleeps between uses. For a sandbox that only sees real use two days a week, go further and default it to off with an on demand start.

Fix two: sample, do not clone

Full production data copies in non production are the second largest waste and the largest risk. A 40 TB copy costs about $920 a month in storage and, worse, every test query scans production volumes: a query that reads 2 TB costs $10 in the sandbox exactly as it does in production. Developers iterating run that query dozens of times a day.

A 1 percent stratified sample, 400 GB, costs about $9 a month in storage and makes each test query 100 times cheaper. Keep the same schema, the same partitioning, and the same edge case rows, so behaviour is representative. Where realistic volume is genuinely needed for performance testing, spin up the full dataset for the duration of the test and tear it down afterwards rather than keeping it permanently. Sampled data also removes the need to hold production personal data in a less controlled environment, which is a compliance win alongside the cost one.

Fix three: size for the job, not the parent

Environment	Compute size	Reasoning
Production	Large	Real concurrency and data volume
Staging	Small	Correctness checks, not load
Development	X-Small	Sampled data, one user at a time
CI pipeline	X-Small, ephemeral	Short lived, tiny fixtures
Performance test	Production sized, on demand	Only valid at real scale, run rarely

Each size step down halves the rate, so moving a dev warehouse from Large to X-Small is a 16x reduction. The only environment that legitimately needs production scale compute is a performance test, and that should exist for hours rather than months.

Fix four: an owner and an expiry

Storage tiering applies here too. Sandbox data almost never needs the hot tier beyond the current week, and snapshots of non production databases rarely need more than a couple of days of retention. Both default to production settings when a module is copied, and both are trivial to override per environment.

Ad hoc sandboxes created for a migration or an experiment are the ones that survive longest, because nobody remembers they exist. Tag every non production environment with an owner and a review date at creation time, and run a monthly report listing environments past their date. Anything unclaimed gets suspended for two weeks and then deleted. The suspension step makes deletion safe: if nobody complains in two weeks, nobody needed it.

The expected result

Applying all four to a cloned environment costing $18,200 a month brings it to roughly $700 to $1,200, a 93 percent reduction, with no loss of development capability. Even a conservative application, scheduling plus sizing but keeping full data, typically reclaims 60 to 70 percent. Encode the differences in Terraform variables per environment rather than duplicating modules, so a dev environment cannot accidentally inherit production sizing, and let C3X price each environment from the resource catalogso the difference is visible in the pull request that creates it.

FAQ

Why do non production data environments cost so much?

They are usually cloned from production Terraform with only a name change, inheriting production warehouse sizes, node counts, data volumes, and schedules. Then they run continuously because nobody owns shutting them down. A cloned sandbox frequently costs more than production itself, since production at least suspends outside business hours.

How much does scheduled shutdown save?

About 70 percent of compute cost. A working week is roughly 50 of 168 hours, so suspending warehouses, terminating clusters, and scaling instance groups to zero outside 8am to 7pm on weekdays eliminates roughly 118 hours a week of billing. Environments used only a couple of days a week can default to off entirely.

Should development environments use production data?

Rarely. A full 40 TB copy costs around $920 a month in storage and makes every test query scan production volumes, so a 2 TB query costs $10 each time a developer runs it. A 1 percent stratified sample costs about $9 a month, makes queries 100 times cheaper, and avoids holding production personal data in a less controlled environment.

How much smaller should a dev warehouse be?

Usually several sizes. Each step down halves the hourly rate, so moving from Large to X-Small is a 16x reduction. Staging needs enough capacity for correctness checks rather than load, development on sampled data needs very little, and only performance testing legitimately requires production scale compute, which should be provisioned on demand.

How do I stop forgotten sandboxes accumulating?

Tag every non production environment with an owner and a review date at creation, then run a monthly report listing anything past its date. Suspend unclaimed environments for two weeks before deleting them. The suspension step makes deletion safe, since if nobody notices the environment is gone for two weeks, nobody needed it.

How does C3X help with environment cost?

C3X prices each environment's Terraform against a live catalog, so the difference between a dev environment that inherited production sizing and one scoped correctly appears as a dollar figure in the pull request. Encoding environment differences as variables rather than duplicated modules then keeps the cheaper shape from drifting back.

What to do next

Stop dev environments inheriting production prices. C3X costs your Terraform resources per environment. Start with the quickstart.