Polars 2.0 Breaks Row Order: Fix Your Pipelines Now

Polars released its 2.0 release candidate on September 2, 2026 — and the biggest change will silently break production pipelines before a single test fails. All LazyFrame.collect() calls now default to the streaming engine, stripping row-order guarantees from joins, group_by, and unpivot operations. The 5x performance improvement is real. So is the data corruption risk if you upgrade without auditing your codebase first.

Polars is now used by 11% of professional Python developers and has doubled its share annually since 2023. For data engineering teams running production ETL on Polars 1.x, this is the most consequential upgrade since the library launched. Ritchie Vink called it a “boring” major version bump. It isn’t.

The Streaming Default: Where Silent Bugs Hide

In Polars 1.x, engine="auto" in LazyFrame.collect() resolved to the in-memory engine — rows came back in predictable order. In 2.0, it resolves to the streaming engine. The streaming engine processes data in batches, which is why it delivers 5x faster performance and can handle datasets larger than RAM. However, operations like group_by, join, and unpivot no longer guarantee output row order.

The danger is silent failure. No exception gets raised — your pipeline just returns aggregations or joins in an arbitrary order. Any downstream code that relies on positional indexing after a lazy operation will produce wrong results without complaint. This is the row-order assumption buried in pipelines everywhere, and 2.0 makes it bite. According to the official Polars 2.0 announcement, this is the most significant behavioral change in the release.

The fix depends on your situation. For individual operations, add maintain_order=True to group_by or maintain_order="left" to joins. For a full rollback while you migrate, set pl.Config.set_engine_affinity("in-memory") once at process startup — this restores the old default process-wide. For per-query overrides, use .collect(engine="in-memory").

# Fix: maintain row order for specific operations
result = (
    df.lazy()
    .group_by("user_id", maintain_order=True)
    .agg(pl.col("amount").sum())
    .collect()
)

# Fix joins with order guarantee
result = df.lazy().join(other, on="id", how="left", maintain_order="left").collect()

# Temporary escape hatch while you audit the full codebase
import polars as pl
pl.Config.set_engine_affinity("in-memory")

Five Other Breaking Changes to Fix Before Final Release

Beyond the streaming default, five explicit breaking changes will throw errors the moment you upgrade. They are easier to catch than the row-order issue — but only if you test against RC1 before final 2.0 ships. The official Polars 2.0 upgrade guide covers all of them in full.

melt() is gone. Replace every df.melt() with df.unpivot() — id_vars becomes index, value_vars becomes on. String-to-date casting is removed. pl.col("date_str").cast(pl.Date) now raises — use .str.to_date() instead. Horizontal concat is strict. pl.concat([df1, df2], how="horizontal") raises ShapeError when heights differ — switch to how="horizontal_extend" for the old null-padding behavior. is_in() rejects lossy coercions. Comparing an Int64 column against a Float64 list now raises InvalidOperationError — explicit casting required. LazyFrame.profile() is removed. The streaming engine makes per-node timing unreliable, so profiling was pulled with no direct replacement.

# melt → unpivot
df.unpivot(on=["a", "b"], index=["id"])

# cast → str.to_date
pl.col("date_str").str.to_date()

# horizontal concat with different heights → use horizontal_extend
pl.concat([df1, df2], how="horizontal_extend")

# is_in with explicit types (no more implicit coercion)
df.filter(pl.col("count").cast(pl.Float64).is_in([1.0, 2.0]))

Related: Python’s Free-Threaded Build Is Stable. Should You Use It?

Test RC1 Now — The Migration Window Is Open

Polars 2.0rc1 is available today via PyPI. The final 2.0 release lands “in the following weeks” — that window is your migration runway, and it is shorter than it looks. Run your test suite against RC1 and the explicit breaks surface immediately. The dangerous ones — row-order assumptions — won’t throw exceptions, so you need to audit those manually.

Four patterns to grep your codebase for right now: .profile() calls (removed), .melt( calls (replace with unpivot), .cast(pl.Date or similar temporal casts (replace with str methods), and how="horizontal" in concat calls (check heights or switch to horizontal_extend). If you find row-order-sensitive code and can’t audit it before final release drops, pin to polars<2.0 in your requirements immediately.

# Install RC1 in an isolated environment and run your test suite
pip install "polars==2.0rc1"
python -m pytest tests/

# Audit for silent row-order risks and explicit breaks
grep -rn "\.profile()\|\.melt(\|\.cast(pl\.Date\|how=\"horizontal\"" src/

“Boring” Is the Wrong Word

Ritchie Vink described Polars 2.0 as a “boring” release — focused on removing deprecated cruft and setting sensible defaults rather than shipping new features. The Hacker News thread echoed this, landing 137 points as developers praised the semantic versioning philosophy: “version bumps should really be about removing deprecated cruft rather than shiny new features.” That framing is right for library maintainers paying down technical debt.

For production engineers, “boring” is the wrong word. Changing the default execution engine and removing row-order guarantees in the process is not a routine upgrade. The quiet changes always bite hardest. Treat this like a major migration and run the full audit before letting 2.0 into production.

Key Takeaways

• Polars 2.0rc1 is available now (pip install polars==2.0rc1); final release expected within weeks — test today, not after it ships
• The streaming engine is now the default for all LazyFrame.collect() calls, removing row-order guarantees for group_by, join, and unpivot — this is a silent data corruption risk, not a visible error
• Add maintain_order=True to row-order-sensitive operations, or use pl.Config.set_engine_affinity("in-memory") as a temporary escape hatch across your whole process
• Grep for four explicit breaking patterns: .melt(, .profile(), .cast(pl.Date, how="horizontal" — these will throw errors immediately on upgrade
• If you cannot audit before final 2.0 ships, pin to polars<2.0 in your requirements now to avoid an unplanned breaking change in CI