Accepted answer
Clones are cheap for storage but not for compute. If every engineer runs heavy queries against their clone on a shared warehouse, you can still rack up real credit costs despite the 'free' storage.
Planning to give each engineer a zero-copy clone of prod schemas for development in Snowflake, refreshed weekly. Sounds too easy. What breaks in practice?
Accepted answer
Clones are cheap for storage but not for compute. If every engineer runs heavy queries against their clone on a shared warehouse, you can still rack up real credit costs despite the 'free' storage.
Prefer a staging table plus validation gate before promoting to prod tables.
Document the grain decision, most BI bugs turn out to be grain bugs.
Plain English: the system prefers to guess a good-enough plan than the perfect plan, because figuring out the perfect plan would take longer than just running the good-enough one.
We replaced custom sensors with data contracts and row count checks.
Worth measuring the serialized size before choosing broadcast.
Prefer a staging table plus validation gate before promoting to prod tables.
Also worth flagging: a clone freezes data at clone time, so 'weekly refresh' means re-cloning, not a live view that updates on its own. Some engineers expect the latter.
In our case the root cause was an implicit cast preventing pushdown.
Start with the execution plan, numbers beat guesses.
In our case the root cause was an implicit cast preventing pushdown.
Start with the execution plan, numbers beat guesses.
Sign in to reply.
© 2026 Lakebench, operated by Hunnurji Rao. Bengaluru, Karnataka, India.
No cluster. No install. Just the tab.