How Melt cuts a Snowflake bill.

Melt cuts a typical agent-shaped Snowflake bill by 75–97% on the same query workload. This page shows the canonical reference workload, the math model, and the inputs that move the number, plus a calculator you can run on your own usage.

TL;DR

For an agent-shaped Snowflake workload, Melt reduces spend two ways:

1. Query routing. For every statement, decide whether the cheap lakehouse engine can answer it. Lake-routed queries pay $0 Snowflake credits.
2. Warehouse routing. For the statements that do stay on Snowflake, pick the smallest warehouse that satisfies the query instead of running everything on the shared oversized one.

On the canonical agent-shaped workload defined below, the combined savings land between 75% and 97% depending on lake-eligible fraction and whether warehouse routing is enabled. The hero quotes the floor.

Canonical reference workload

Every input is a knob in the calculator. Defaults match this table.

The cost model

Every query on Snowflake bills warehouse credits proportional to its active-warehouse seconds:

cost(query) = (latency_seconds / 3600) × credits_per_hour(warehouse) × credit_rate

This is the same model our open-source bench harness uses, and it sanity-checks against the observed bench numbers: 100 queries × 142 ms × 8 credits/h × $3 / 3600 ≈ $0.095, vs $0.102 measured.

Lake-routed queries run on DuckDB locally over Parquet on S3, with zero Snowflake credits. The Melt host’s compute is real but small, and out of scope for v1.

Lake-routing-only savings

For a workload of N queries with lake-eligible fraction f:

baseline_cost = N × avg_latency × credits_per_hour × credit_rate / 3600
melt_cost     = (1 − f) × baseline_cost
savings       = f × baseline_cost

Plugging the canonical inputs (100k/mo, 150 ms, L, $3, f=0.85):

• baseline = 100,000 × 0.150 × 8 × 3 / 3600 = $100/month
• Melt = 0.15 × $100 = $15/month
• savings = $85/month, 85% reduction

Warehouse-routing savings on the Snowflake residual

Right-sizing each statement to its smallest sufficient warehouse converts a shared-LARGE baseline into a mixed pool. Snowflake publishes per-size credit rates (XS=1, S=2, M=4, L=8, 2XL=16, …); the weighted-mean credits/hour for the canonical mix is:

mix_credits_per_hour = 0.60×1 + 0.25×2 + 0.12×4 + 0.03×8 = 1.82
ratio                = 1.82 / 8 = 22.75%
warehouse_savings    = 77.25% on the Snowflake-residual portion

Combined savings

Combined savings as a fraction of baseline spend:

savings_fraction = f + (1 − f) × (1 − mix_ratio)
                 = f + (1 − f) × 0.7725

On the canonical inputs (f = 0.85):

savings_fraction = 0.85 + 0.15 × 0.7725 = 96.6%
combined_melt    = $3.41/month
combined_savings = $96.59/month

Why the hero quotes 75% as the floor. With warehouse routing off, you’d need a lake-eligible fraction below 0.75 to fall under 75% savings. With warehouse routing on, you’d need to drop below 0.32. On a Medium-baseline warehouse you’d need lake fraction below 0.75. Slide the calculator above to test your own workload — the upper bound on the canonical inputs is 96.6%.

What the figure does not include

• Melt host compute. DuckDB cycles on the Melt host are real but trivial vs. Snowflake credits at the scale Melt is built for. Not counted.
• Sync infrastructure cost. Lake routing only works if the underlying tables are synced to object storage. S3 (or equivalent) storage + transfer is a real line item; for the design-partner cohort it’s ~1–3% of the displaced Snowflake spend. Not counted in the headline.
• Cold-start tax. A warehouse that has fully suspended pays a 1-minute credit floor when it wakes. The model assumes the warehouse is already warm for the Snowflake-residual fraction; if the fall-through traffic is sparse, real-world savings are 5–15% lower until per-statement warehouse routing ships.
• Edition multipliers and consumption commitments. Real bills include Enterprise/Business-Critical multipliers, serverless adjustments, and contractual rate discounts. Override credit_rate in the calculator to match a specific contract.

What changes the figure

• Workload shape. A workload that’s already 100% large aggregates can’t be lake-routed and won’t move with Melt; conversely, an LLM-agent workload with 95%+ small reads compresses harder.
• Lake-eligible fraction. Tables not in the sync allowlist, queries in enforce policy mode that hit policy-protected tables, and queries with Snowflake-specific features (semi-structured FLATTEN, scripting, external functions) all fall through to passthrough.
• Baseline warehouse size. Customers who already right-sized warehouses on their own see less from warehouse routing. Customers running everything on a shared LARGE or larger see the full effect.
• Workload concurrency / cold-start frequency. A bursty agent fleet that wakes the warehouse repeatedly pays the cold-start floor more often than the model assumes.

Re-measure with our public bench harness on any workload you care about. Same model, your numbers.

How the hero number stays honest

• The hero copy quotes the floor, not the median or upper bound.
• The hero copy links to this page from “75%”.
• FAQ schema (homepage) is workload-dependent: “Savings depend on workload shape, lake-eligible fraction, and baseline warehouse size. See the methodology page for the math and a calculator.”
• Every blog or comparison number that quotes a % reduction either:
  1. cites this page and uses the canonical reference inputs above, or
  2. publishes its own workload shape + inputs in the same paragraph.

References

• Public bench harness: github.com/CITGuru/melt/tree/main/examples/bench
• Snowflake warehouse pricing: snowflake.com/pricing