BW
Language / اللغة:
Services & Practices
All 9 Practices Overview →
Sectors & Work
Insights & Stack
Company
Start a Project

September 2026 · 3 min

FinOps for Snowflake and Databricks: a 30% spend cut, not a fantasy

Practical patterns we use to cut Snowflake and Databricks warehouse spend by 25–45% without slowing analytics.

Snowflake and Databricks FinOps is the same pattern, with different knobs. Here is what works, in our experience, at regulated enterprises.

1. Tag everything. Every Snowflake object (warehouse, database, schema, table) and every Databricks object (cluster, job, notebook) needs a tag that maps to the cost owner. Without tags, you cannot allocate cost — and you cannot optimize it.

2. Right-size warehouses / clusters. Snowflake: X-Small / Small for most queries, Medium only for heavy workloads, Large / X-Large only for the nightly batch. Databricks: cluster policies that cap instance type and count, autoscaling with min/max workers, spot instances where possible.

3. Auto-suspend aggressively. Snowflake warehouses auto-suspend after 60 seconds by default; many shops set 10 seconds. Databricks jobs terminate on completion. The default is too generous; tighten it.

4. Query acceleration & result caching. Snowflake’s query acceleration service, result cache, and materialized views all reduce compute. Databricks’ Photon engine, Delta Cache and Liquid Clustering all reduce compute.

5. Dynamic tables / materialized views. Snowflake Dynamic Tables and Databricks Delta Live Tables both reduce the cost of incremental transformations by 50–90% vs nightly batch.

6. Cluster policies. Snowflake: per-user / per-role warehouse size limits. Databricks: cluster policies that enforce max instance type, max workers, tag compliance, and auto-termination.

7. Capacity commitments. Snowflake capacity commitments and Databricks commit commitments are the biggest lever — typically 30–60% off on-demand pricing. We recommend committing 60–70% of expected usage once the pattern stabilizes.

8. Workload isolation. Separate warehouses / clusters for ETL, BI and ad-hoc. Ad-hoc workloads get a small, aggressive warehouse; ETL gets a right-sized cluster; BI gets a stable, larger warehouse. This stops ad-hoc from blowing up the BI budget.

9. Anomaly detection. Snowflake has METRICS and a Snowflake Cortex-based anomaly detection. Databricks has system tables and DBSQL query history. We wire both into a FinOps dashboard with alerts on anomaly.

10. Chargeback / showback. Every cost center gets a monthly invoice for their Snowflake / Databricks usage. The bill goes to the cost owner, not the central data team. Behavioral change is the biggest lever.

11. Query rewriting. dbt + query rewriting for the top 10 most expensive queries. Usually 2–3 queries account for 40–60% of warehouse spend. Rewriting them with clustering, partition pruning, or a different join strategy yields 5–10× cost reduction.

12. Storage optimization. Snowflake: fail-safe, time-travel, automatic clustering can balloon storage costs. Databricks: Delta log, vacuum, optimize. Both have storage-cost levers that are usually missed.

13. Monthly FinOps review. The data team, the FinOps team, finance and a representative from the largest cost center. Show the trend, the actions taken, the actions planned. Make it boring and consistent.

14. Engineer the FinOps, don’t buy it. Snowflake / Databricks have FinOps tools but they are not enough. We add Monte Carlo, Datadog, Cloudability or equivalent for full observability.

Outcome: 25–45% spend reduction in year one, with no slowdown in analytics or ML. The savings typically fund the FinOps program for 3–5 years.

Engineering notes, every other week

More from ByteWave

Architecture, migration playbooks and AI governance from the delivery teams.

Browse all blogs & insights