Warehouse Architecture Decision for a Team Outgrowing Snowflake's Cost Profile

An analytics-heavy team that had standardized on Snowflake several years earlier. The choice had been correct at the time — Snowflake's combination of performance, simplicity, and team familiarity had been hard to beat. The team's query patterns had since evolved into a category where Snowflake's cost curve had become structurally difficult to defend.

Specific workloads had migrated toward patterns Snowflake handled expensively — very large scans, repetitive batch transformations, high-concurrency dashboards refreshed at short intervals. The Snowflake bill had grown faster than the value the team was extracting from it for these workloads. The leadership wasn't looking to abandon Snowflake — it was the right tool for many workloads — but they wanted to understand which workloads would benefit from a different tool and what the migration cost would look like.

A workload-level audit of the team's Snowflake usage paired with a partial migration to alternative tools where the analysis supported the move.

The audit decomposed the Snowflake workload by query pattern, by warehouse size, by frequency, and by cost. The output was a clear view of which workloads were Snowflake-appropriate and which weren't. Several patterns emerged. The interactive analytical workloads that had originally justified Snowflake remained well-served by it. The repetitive batch transformations had grown into the category where ClickHouse or DuckDB on the underlying lake storage would be substantially cheaper for the same outputs. The high-concurrency dashboard workload had grown into the category where a dedicated query layer in front of a cheaper storage backend was the better fit.

The migration was structured around the workloads where the analysis supported the move:

Repetitive batch transformations were migrated to dbt models running against ClickHouse for the cost-sensitive workloads. The dbt model interface stayed familiar to the team while the underlying compute economics changed substantially.

The high-concurrency dashboard layer was rebuilt against a dedicated query engine — Apache Pinot in this case — sourcing from the lake storage rather than reloading data into Snowflake for the dashboard layer.

The interactive analytical workloads stayed in Snowflake. The team's analysts continued to work against the same interface they were used to, with no migration friction for the work that mattered most to them.

The architectural decisions were documented so that future workloads could be assigned to the appropriate tool from the start rather than defaulting into Snowflake regardless of fit.

The team's overall warehouse spend decreased substantially while the workloads that benefited from Snowflake continued to operate on it. Migration friction was minimized because the most-used interactive interface didn't change. The team gained the conceptual framework — and the operational tooling — to make tool choices per workload rather than per organization.