CS-02 — Architecture & performance · Data platforms · Cloud architecture

Performance and cost optimisation in Snowflake

Optimisation of numerous reports and of the daily C# processes that pre-compute their data with advanced queries, combining PostgreSQL and Snowflake according to compute needs; includes pruning, joins, data types, VARIANT columns and analysis of warehouse and storage costs.

My role: Senior Data Engineer (Wizeline), responsible for the optimisations and investigations described.
Period: Not documented
Disclosure: Anonymised details
Technologies: SnowflakePostgreSQLSQLC#.NETAmazon S3AWS
Last reviewed: 13 November 2026

Context

Some regional analytics stored procedures had excessive execution times, affecting reports and, in some cases, causing application timeouts. In parallel, the platform's cost was being reviewed: warehouse usage, idle time and S3 storage.

Challenges

01Long-running queries and inefficient stored procedures.
02Excessive micro-partition scanning due to a lack of effective pruning.
03Joins between JSON-derived values and integer columns that prevented pruning.
04Warehouse cost, idle time and storage.
05Daily processes that pre-compute report data with complex queries.

Solution & architecture

Optimisation of numerous reports and of the daily processes developed in C# that calculate pre-computed data for the reports with advanced queries, running each calculation in PostgreSQL or Snowflake according to compute needs. Analysis of query profiles and execution plans, rewriting of predicates, explicit type conversions in joins with JSON/VARIANT-derived values, improved joins and comparison of results across environments. On cost, review of warehouse utilisation and idle time, S3 storage classes and workload scheduling.

Key decisions

D-01

Fix data types and predicates before scaling the warehouse

The bottleneck was pruning, not compute capacity; a larger warehouse would have cost more without addressing the cause.

D-02

PostgreSQL or Snowflake according to compute needs

Not every calculation needs a warehouse; those that do go to Snowflake and the rest are handled in PostgreSQL.

Trade-offs

Not documented yet

Results

Substantial reduction in the execution time of complex analytics procedures in a development benchmark.

Lessons learned

A misaligned data type in a join can defeat micro-partition pruning and dominate execution time.

This work reflects an approach to engineering in which reliability, maintainability and cost efficiency are considered together. Procedure names, client query structures and benchmark figures are not published.

Ask about this case study

Ask about this case studyAI · answers from an approved knowledge base · not Ander in real time

Questions here are answered with the case study “Performance and cost optimisation in Snowflake” as context.