Polars 2.0 makes the streaming engine the default and stops guaranteeing row order

Polars published py-2.0.0-rc.1 on 2 September 2026, marked as a pre-release. The release notes list exactly one breaking change: "Set the default engine for SQL to the streaming engine." The project's own upgrade guide explains what that does to results, and it is the part worth reading before anyone upgrades.

The default moved without the setting changing

The upgrade guide states that LazyFrame.collect and collect_async "still default to engine="auto", but "auto" now resolves to the streaming engine for lazy queries." Nobody has to opt in. Code that names no engine at all gets the new one.

The guide is direct about the consequence. It says the change "may silently impact the results of your pipelines," because "the streaming engine does not guarantee row order for operations that don't require it (unpivot, group_by, joins, ...)."

The example the project gives is a left join. Under the new default, a left join no longer returns rows in the order of the left-hand frame. The guide's advice for anyone depending on that is to sort explicitly, or to pass maintain_order on the operations that support it.

Silent is the word that matters

Most breaking changes announce themselves. An import fails, a signature rejects an argument, a test goes red on the line that changed. This one does none of that. A pipeline that quietly assumed the order it always happened to get will keep running, keep returning the right rows, and return them arranged differently.

That failure surfaces wherever the order was load-bearing without being written down: a report where the first row was treated as the top result, a file written for a downstream consumer that reads positionally, a snapshot test that compares output line by line. The last of those is the lucky case, because it fails loudly.

Polars is a widely used library rather than a niche one. The GitHub API returned 39,659 stars and an MIT licence for pola-rs/polars when the repository was checked on 6 September 2026. The project has existed since May 2020 and is written in Rust.

Where the risk actually sits

The upgrade itself is easy to reason about. The hard part is finding the places in an existing codebase that depend on ordering nobody ever declared, because by definition those places are not marked. Grep finds sort calls. It does not find the absence of one.

This is a reasonable moment to make the dependency explicit rather than to pin the old behaviour and move on. Passing maintain_order where the order genuinely matters documents the requirement in the code, and it keeps working regardless of which engine a future release defaults to. Pinning the version defers the same audit to a less convenient week.

It is still a release candidate, so there is time. Testing against the pre-release now costs less than discovering the reordering after a stable 2.0 lands and a report comes out wrong.

Source

Polars py-2.0.0-rc.1 release notes and the Polars 2.0 upgrade guide. Star count, licence and creation date read from the GitHub API on 6 September 2026. Surfaced by The New Stack.