Theory
The bill is a design surface, on every platform
Managed platforms make compute trivial to consume, which is exactly why bills explode. The discipline (FinOps) is the same across all three even though the meters differ:
- Attribute every cost to an owner — Tag warehouses/clusters/reservations and queries by team. Snowflake: per-warehouse credits +
QUERY_HISTORY. Databricks: cluster tags + system tables. BigQuery: labels +INFORMATION_SCHEMA.JOBS. When each team sees their spend next to their OKRs, behaviour changes without policy. - Kill idle and runaway spend — Auto-suspend warehouses (Snowflake), auto-terminate clusters (Databricks), and
require_partition_filter+ byte-cap custom quotas (BigQuery). The top-20 most expensive queries each week are usually where 30% of the savings hide — find and fix them. - Design for portability — Lock-in is a spectrum. Keep transformations in dbt / open SQL and storage in open formats (Iceberg/Delta) where you can, so a migration is re-pointing compute, not rewriting the warehouse. Avoid deep use of one vendor's proprietary functions in business-critical models unless the payoff is large.
- Migration reality — Moving platforms means porting SQL dialects, re-tuning data layout (clustering ≠ partitioning ≠ micro-partitions), re-implementing RBAC, and re-validating numbers. Plan it as months and a parallel-run, not a weekend.
Use Case Example: A team standardises every transform in dbt and stores curated tables as Iceberg/Delta. When finance mandates a move from on-demand BigQuery to a Snowflake reservation, ~80% of the work is dialect tweaks and re-clustering — the models and open storage come along unchanged, turning a rewrite into a re-point.