Skip to main content

Snowflake cost optimization with chukei

chukei is a Snowflake cost optimization engine and transparent wire-protocol proxy. It reduces repeated Snowflake read-workload compute spend with verified result caching, warehouse auto-suspend, SQL rewriting, per-team cost attribution, and signed savings evidence.

chukei runs in your own VPC. Your BI tools, dbt jobs, JDBC clients, and Python applications keep their credentials and SQL, point at a different host, and chukei optimizes the query path with zero client changes.

Snowflake-only launch scope

chukei currently supports Snowflake only. It is designed for read-heavy analytics workloads such as BI dashboards, reporting, dbt model reads, and ad-hoc analysis.

Start here — pick your path

I'm…Start with
🔍 Evaluating chukeiProduction validation resultsis a proxy safe?replay your own QUERY_HISTORY
🚀 Getting startedInstall chukei10-minute quickstartconnect dbt / JDBC / Python
⚙️ Operating in productionProduction pilotKubernetessecurity modeltroubleshooting
📊 Attributing & proving savingsSnowflake FinOpsthe cost optimization frameworksigned savings evidence

New to Snowflake cost optimization as a discipline? Start with the framework and the cost optimization guide.

How it cuts the bill

LeverWhat it does
Verified result cachingIdentical deterministic reads are served from cache and continuously double-checked against live Snowflake. In a 13.5-hour production soak: 60,000 cache hits, zero mismatches.
Warehouse auto-suspendAn idle-detection sweeper suggests (or, with a service account, executes) warehouse suspends. In simulation this is ~94% of total savings.
SQL rewritingEquivalence-tested rewrite rules turn expensive query shapes into cheaper ones inline.
Cost attributionEvery query is attributed to a team, BI tool, or dbt model at the proxy — no tagging discipline required.
Signed savings evidenceRealized savings are ledgered conservatively and exportable as Ed25519-signed evidence bundles.

What problems does chukei solve?

Snowflake cost problemchukei answer
Repeated BI dashboard queries consume warehouse credits all dayVerified query caching avoids repeated compute for deterministic reads
Warehouses stay running after traffic dropsWarehouse auto-suspend detects idle windows and can start in suggest-only mode
Nobody owns the Snowflake billSnowflake FinOps attribution maps cost to teams, tools, users, and dbt models
Savings are hard to prove to financeSigned evidence bundles record avoided spend with conservative methodology

Why an engine in the query path?

Most cost tools are dashboards, advisors, or copilots — they tell you what to change and wait for humans to act. chukei sits in the query path as a transparent proxy, so the optimization happens without anyone changing queries, BI tools, or behaviour — and it's deterministic Rust, not an LLM guessing. Any chukei-side failure degrades to verbatim passthrough: a parse error, cache miss, or plugin panic never breaks a query. Is a proxy in front of Snowflake safe? — every classic objection, answered with measured numbers.

Apache-2.0 license

chukei is open source under the Apache License, Version 2.0. You can use, modify, and redistribute it under the terms of the license.

Key properties

  • Deterministic hot path — no LLM, no network calls beyond the upstream forward; measured proxy overhead ~2ms p99
  • Fail open — every failure mode degrades to passthrough
  • False-positive-intolerant cache — non-deterministic queries, writes, and chunked responses are never cached
  • Credentials pass through — chukei never stores or logs client credentials

Next steps