Polars 2.0 makes streaming automatic and implicit row order explicit

Ritchie Vink's release candidate lowers memory demands while tightening the rules around ordering, type coercion and malformed data.

By · Published

Primary source: Polars

Why it matters

Vink is turning years of streaming work into default behavior, cutting memory demands while forcing teams to expose ordering and type assumptions before production.

An abstract visualization of data transformation, showing chaotic data entering a clear processing system and emerging as perfectly ordered, luminous rows.

Polars creator Ritchie Vink released the first candidate for Polars 2.0 on September 2nd, making the library's streaming engine the default for lazy queries and tightening behavior that could previously conceal malformed data.

Vink is deliberately underselling the version number. He said he hopes the upgrade will be a "boring experience" because 2.0 carries few marquee features. The major release gives Polars room to remove old design decisions and change defaults that now constrain the query engine.

That restraint fits the way Vink has built Polars since starting the open-source project in 2020. Polars began as a pet project for learning Rust, Apache Arrow and query-engine design. Vink later turned a performance exercise into a DataFrame library and, in 2023, formed Polars with Chiel Peters, the former chief technology officer of Dutch data consultancy Xomnia.

Vink initially experimented with copying pandas' API. He recalled in a 2024 interview that the approach clashed with his preference for predictable output types and stricter contracts. Polars 2.0 pushes that preference into the default behavior developers encounter.

The release candidate is available from PyPI as version 2.0.0rc1. Polars expects the final release within the next several weeks, without specifying a date.

Streaming becomes the ordinary path

Calling collect() on a Polars LazyFrame previously resolved to the in-memory engine unless a developer explicitly selected streaming. In 2.0, the existing engine="auto" setting resolves to streaming instead.

Streaming divides a query into batches rather than requiring the complete dataset and intermediate results to remain in memory. That execution model lets Polars process datasets larger than the available RAM and can improve performance on supported operations.

Polars expects the streaming engine to be about five times faster in aggregate. That figure comes from Polars' own benchmarks rather than independent testing. In a PDS-H benchmark published June 1, 2025, Polars reported that streaming was 2.5 times faster than its in-memory engine at SF10 and about 6.4 times faster at SF100. PDS-H is derived from TPC-H but is not an audited or compliant TPC-H benchmark, and results will vary by query and hardware.

The speed and memory gains carry a behavioral cost. Streaming does not preserve incidental row order for operations such as joins, group_by and unpivot. A pipeline that assumes a left join will retain the left DataFrame's existing order may produce differently ordered rows after the upgrade, even when its values remain correct.

Polars' 2.0 migration guide tells developers to sort explicitly or request observable order through settings such as maintain_order="left". Teams can also retain the previous engine globally with pl.Config.set_engine_affinity("in-memory"), or select the in-memory engine for an individual query.

That is the central bargain in Vink's release: Polars will choose the execution path designed to use less memory and run faster, while applications must stop treating accidental ordering as a contract.

A stricter contract for data pipelines

Polars 2.0 also turns several permissive behaviors into errors. The sharpest example involves is_in, which previously found a common type when comparing mismatched data types, even when conversion could lose information.

A 64-bit user ID above 2^53, the largest integer that a 64-bit floating-point value can represent exactly, could be rounded during conversion and incorrectly match a neighboring ID. Polars 2.0 raises an InvalidOperationError instead and requires the developer to choose an explicit cast.

Horizontal concatenation receives the same treatment. Polars previously padded a shorter DataFrame with null values when combining it with a taller one. In 2.0, the default raises a ShapeError. Developers who intentionally want padding can request horizontal_extend.

Vink is applying the same principle to older APIs. Polars removed ambiguous casts from strings to date and datetime types in favor of dedicated parsing methods such as str.to_date(). Removed methods and arguments increasingly raise AttributeRemovedError or ArgumentRemovedError with guidance toward a replacement. The migration guide warns that coverage for those specialized exceptions is not complete.

Polars connects this stricter behavior to AI-generated code. An agent can call collect_schema() to resolve types and detect schema mismatches before materializing data. Early validation shortens the feedback loop for an agent writing queries, though errors that depend on actual values still surface during execution.

The AI framing is timely marketing, but the underlying design choice predates coding agents. Vink has consistently treated unpredictable types, silent coercion and data-dependent behavior as liabilities. Agents make those liabilities easier to create at volume.

The open-source engine is also the commercial engine

The default change arrives after years of investment in streaming across Polars' open-source and paid products. Vink and Peters formed Polars in August 2023 with a roughly $4 million seed round led by Bain Capital Ventures. Polars raised a further roughly $21 million Series A led by Accel in September 2025, with Bain Capital Ventures participating again.

Polars sells Polars Cloud and an on-premises distributed engine built around the same API as the local library. Making streaming the standard local path reduces the semantic gap between a developer's laptop and the infrastructure Polars wants that developer to buy later.

Polars currently claims more than 775 million downloads and 39,000 GitHub stars on its homepage. Those figures are self-reported and do not reveal active users or paying customers, but they show the scale of the upgrade surface. A default that changes row ordering can reach far beyond developers who actively follow release notes.

Vink has consequently made 2.0 less of a feature showcase than a cleanup of Polars' contract with its users. Streaming becomes ordinary. Silent coercion becomes an error. Ordering becomes an explicit requirement. The result may feel boring when a pipeline's assumptions are sound. When they are not, Polars 2.0 is designed to say so sooner.

Reader comments

Conversation for this story loads after sign-in.