Polars py-1.42.0 - Cloud IO and Query Planning Updates

Polars py-1.42.0 was published on June 24, 2026, with cloud IO controls, Parquet and Delta file pruning, and targeted fixes for SQL, streaming, and sink workloads. For data engineering teams using Polars in batch or lakehouse jobs, the most important change is less wasted scan work through bytes based cloud concurrency, row group skipping, and better metadata resolution. This is a regular release, not a prerelease.

The full release notes and downloads are on the GitHub release page.

Cloud IO and scan planning get more predictable

Cloud backed scans are the clearest operator facing part of this release. Polars now has bytes based concurrency control for cloud IO, plus DNS caching and shuffle behavior for cloud object_store access. That matters when a scan is bound by object store fetch patterns rather than CPU.

External object_store support for non native schemes also expands where scans can originate without forcing every path into the native schemes. The notes also call out a tiered multi file Parquet metadata resolver. In practice, this should make large partitioned datasets cheaper to inspect before the engine commits to reading data pages.

File skipping improves as well. Polars can skip Delta files and Parquet row groups using per field struct statistics. For lakehouse tables with nested struct columns, that is the part of the release to test against real predicates, because it can remove IO before projection and filter work begins.

Planner and SQL changes affect pipeline results

Several query planner changes are relevant for ETL jobs that use lazy plans as the boundary between extraction and loading. The optimizer can eliminate filters with contradictory predicates, improve sortedness detection for with_row_index and explode, and optimize comparisons involving len and null_count. These are not syntax changes, but they can affect plan shape and memory pressure.

SQL users get support for implicit JOIN syntax, computed group keys in SQL projections, and lowering of SQL [NOT] IN (subquery) to semi and anti join forms. The release also fixes join alias state leakage in SQL CTEs. If your pipeline emits SQL from templates, those fixes are more interesting than they look, because they reduce cases where generated SQL needs special casing.

The release notes also include suggestions for wrong API usage or mismatched column names. That is a small ergonomics change, but it helps batch jobs fail with a useful message instead of turning a simple schema drift into a longer incident.

Streaming and sink behavior get targeted fixes

Streaming gets both performance and correctness work. The notes call out faster struct unnest inside list eval on streaming, avoiding duplicated map_elements warnings on the streaming engine, and a fix for calls that can originate from an executor thread. These are narrow items, but they sit close to production execution paths.

Sink users should read the bug fixes. Cross join predicates were not applied when using sink_* functions, and this release fixes that. There is also a fix for SchemaError with lazy HConcat into Sink, plus a correction for projection pushdown with row index order.

Other correctness fixes are around ordering and shape. Slice expressions now observe input order, projection pushdown no longer gives the wrong schema order for hstack, selecting only literals no longer reports the wrong projection height, and select(len()) with scan_iceberg and a pyiceberg reader override no longer incorrectly returns zero. These are the kind of details that matter when Polars sits inside a scheduled load job and the output shape is part of a contract.

Upgrade notes

Two deprecations need attention. Casting from string to temporal dtypes is deprecated, so pipelines that parse dates and times should move toward explicit parsing paths rather than relying on broad casts. The release also adds a deprecation warning for .explode() without the empty_as_null argument.

Polars also adds experimental strict mode and naive out of core spilling. Both are worth isolating in tests before enabling in a shared job runner. Strict mode can expose ambiguous API use earlier, while spilling changes the memory profile of workloads that would otherwise press against container limits.

The documentation updates include a note on OOM behavior on Kubernetes and fixes around On Prem license Helm values, AWS connectivity, cost, and egress sections. That is operational material rather than API surface, but it is relevant when Polars jobs run near memory limits or in controlled cloud accounts.

Where to get it