Cut your Snowflake bill by 75%, without changing a query.

Melt is a self-hosted Rust proxy that sits in front of Snowflake. Drivers connect to Melt as if it were Snowflake, and for every incoming statement Melt makes a per-query routing decision: most reads run on a DuckDB-backed lakehouse on S3 (Iceberg or DuckLake), while writes and Snowflake-specific work pass through to Snowflake unchanged. The lake copy stays current via CDC streams pulled out of Snowflake, so the answer the lake returns is the answer Snowflake would have returned.

Query optimizers rewrite or re-time your SQL so Snowflake runs it more efficiently — the work still runs on the warehouse. Melt does not touch your SQL; it routes each statement to the engine that returns the same result for the lowest cost. When the answer is the lake, the warehouse never spins up at all, so there are no credits to optimise. The two approaches are complementary, but only routing removes traffic from Snowflake entirely.

Select tells you what your warehouse cost; Melt changes what the warehouse runs. Dashboards are observability — they help you right-size, attribute, or chargeback, but every query still hits Snowflake. Melt is an active proxy that decides per query whether Snowflake compute is required at all, and exports the same routing decisions to Prometheus and structured logs so you keep the visibility you had.

No. Melt speaks Snowflake’s REST wire protocol exactly, so JDBC, ODBC, the Python connector, Go, Looker, Sigma, Hex, and dbt connect unmodified. The only change is the connection-string host. Dialect deltas like IFF, QUALIFY, DATEADD, and PARSE_JSON are handled inside the proxy when a query routes to the lake, so your queries stay portable. Snowflake-only constructs (Snowpark, GENERATOR, INFORMATION_SCHEMA access, Time Travel, lateral FLATTEN) pass through to Snowflake unchanged rather than being rewritten.

For every statement, the router parses the SQL, classifies it (writes and Snowflake-only features always pass through), checks that all referenced tables are synced and active, applies your policy mode, and checks the estimated scan against a configurable byte cap. Eligible reads run on DuckDB against Iceberg or DuckLake on S3; everything else forwards to Snowflake verbatim. The decision is observable in /metrics, in structured logs, and offline via melt route "<sql>", which prints the route, the typed reason, and the translated DuckDB SQL.

The biggest savings come from accounts dominated by small, high-frequency reads — BI dashboards refreshing on a tile cadence, agent fleets firing thousands of lookups per day — where each query bills a Snowflake minimum but scans well under a gigabyte. Workloads that are mostly large joins or Snowflake-only features see smaller savings because those keep passing through. The hero figure on this site is workload-dependent and assumes a routable read mix; a published method and an interactive calculator will sit alongside the claim.

Melt is deployed in your own infrastructure. It has two services — a stateless proxy that scales horizontally and a single-writer sync that pulls Snowflake CDC into the lakehouse — and runs against your own Postgres catalog and S3-compatible storage (AWS, MinIO, Cloudflare R2, Backblaze B2, or Wasabi). Snowflake credentials, the lakehouse, and the data plane all stay inside your network.

Policy is configurable in three modes. The default passthrough mode forces any table with a Snowflake policy marker straight to Snowflake. allowlist keeps anything outside an explicit list off the lake. enforce rewrites references to sync-maintained filtered views so row-access and masking policies are honoured on the lake side. Sync polls Snowflake’s POLICY_REFERENCES on a configurable interval and refreshes markers without a restart.

The Docker quickstart brings Melt up against a local Postgres and MinIO in one command, and routing decisions can be inspected immediately with melt route "<sql>" — no Snowflake credentials required to try the router offline. For a real Snowflake account, configuration is a single melt.toml file (account, sync allowlist, backend selection) and pointing your drivers at Melt’s host. Production splits proxy and sync across pods; the shape is documented in the architecture guide.

Yes. Anything that speaks Snowflake’s REST shape works unmodified — the official Snowflake Python connector connects to Melt with only host and port changed. JDBC and ODBC clients (Looker, Sigma, Hex, Tableau), Go, and dbt behave the same way. AI agents that generate SQL via these drivers route through Melt automatically, and they are typically the workload that gets the largest cost win because their queries are individually small and frequent — exactly the shape where Snowflake’s per-query minimums hurt most.