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.
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.
How it cuts the bill
| Lever | What it does |
|---|---|
| Verified result caching | Identical 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-suspend | An idle-detection sweeper suggests (or, with a service account, executes) warehouse suspends. In simulation this is ~94% of total savings. |
| SQL rewriting | Equivalence-tested rewrite rules turn expensive query shapes into cheaper ones inline. |
| Cost attribution | Every query is attributed to a team, BI tool, or dbt model at the proxy — no tagging discipline required. |
| Signed savings evidence | Realized savings are ledgered conservatively and exportable as Ed25519-signed evidence bundles. |
What problems does chukei solve?
| Snowflake cost problem | chukei answer |
|---|---|
| Repeated BI dashboard queries consume warehouse credits all day | Verified query caching avoids repeated compute for deterministic reads |
| Warehouses stay running after traffic drops | Warehouse auto-suspend detects idle windows and can start in suggest-only mode |
| Nobody owns the Snowflake bill | Snowflake FinOps attribution maps cost to teams, tools, users, and dbt models |
| Savings are hard to prove to finance | Signed 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.
Fair-source license
chukei is fair-source under FSL-1.1-ALv2. That means the source is public and usable for permitted purposes, including internal production use, but the license blocks using chukei to offer a competing product or hosted service. Each release converts to Apache-2.0 two years after it is made available.
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
- Production validation results — the live test matrix, soak numbers, and signed evidence
- Install chukei and run your first savings report in 10 minutes
- Replay your own QUERY_HISTORY to project 30-day savings offline
- Snowflake Cost Optimization Guide — the vendor-agnostic engineering guide
- Snowflake Query Caching Guide — native result cache vs verified proxy caching
- Snowflake Warehouse Management Guide — auto-suspend, sizing, and idle spend
- Snowflake FinOps Guide — attribution, showback, and signed savings evidence