2026 Performance improvements¶

Important

Performance improvements often target specific query patterns or workloads. These improvements might or might not have a material impact on a specific workload.

The following performance improvements were introduced in 2026:


Released	Description	Impact
April 2026	Improved runtime pruning for expressions with TIMESTAMP_TZ data types. Snowflake now prunes micro-partitions more effectively for timestamp-based filter predicates.	Improves performance for time-series queries with timestamp filters by skipping significantly more irrelevant micro-partitions, reducing I/O and execution time.
April 2026	Continued improvements to skew handling in hash joins, further reducing processing bottlenecks from unevenly distributed data.	Improves execution time for join queries with data skew by dynamically adjusting redistribution based on warehouse configuration.
March 2026	Enhanced parallel scanning for queries accelerated by the Query Acceleration Service (QAS).	Improves execution time for QAS-accelerated queries by enabling more parallel I/O during scan operations.
March 2026	Dynamically adjusts network message sizes based on the execution plan to optimize data transfer between processing nodes.	Improves execution time for interactive and latency-sensitive workloads by reducing network overhead. Particularly benefits short-running queries and high-concurrency scenarios.
March 2026	Improved scanset construction to reduce lock contention during parallel query execution.	Improves execution time for scan-heavy queries, especially on larger warehouses with high concurrency. Reduces CPU overhead during parallel scan coordination.
March 2026	Identifies opportunities to push aggregations earlier in the query plan when common table expressions (CTEs) are present.	Improves execution time for complex queries with CTEs by reducing the volume of data processed in later stages of the query plan.
March 2026	Improved extraction pushdown through view columns, enabling more efficient scan and metadata usage for subcolumns accessed through views.	Improves execution time for queries that access subcolumns through views.
February 2026	Performance improvements to the file pruner, reducing per-file pruning overhead for queries scanning many files.	Faster pruning decisions during compilation and execution, especially for queries that scan tables with many micro-partitions.
February 2026	Improved range-based micro-partition pruning for more query patterns.	Reduces both compilation and execution time for queries with range predicates by skipping more irrelevant micro-partitions.
February 2026	More efficient aggregation processing when data fits on a single server node, avoiding unnecessary distributed processing overhead.	Improves performance for aggregation queries where the data volume doesn’t require distributed computation.
January 2026	Improved query performance with Snowflake Optima Metadata, which continuously analyzes your workload patterns and creates metadata to optimize pruning of unused micro-partitions. Snowflake Optima is only available on Snowflake generation 2 standard warehouses (Gen2).	Improves performance of queries by creating metadata for more efficient pruning.
January 2026	Improved pruning for join queries with inequality predicates. For example, the following join query uses the `>` operator in an inequality predicate: SELECT * FROM employees e, managers m WHERE e.employee_id = m.employee_id AND e.salary > m.salary AND m.level = 'M5'; For this query, Snowflake prunes micro-partitions from the `employees` table where all salaries are below the lowest `M5` manager salary.	Improves the performance of join queries that have inequality predicates.
January 2026	Faster JSON parsing for PARSE_JSON operations.	Improves execution time for queries that parse JSON data. Queries with heavy JSON processing may see significant speedups.
January 2026	Improved compilation performance for queries with deeply nested CASE expressions by keeping them in a simplified form throughout the compilation process.	Reduces compilation time for queries with large CASE expressions, especially those with many branches.