The Polars team released the first release candidate for Polars 2.0, a major version intended less as a feature showcase than as a reset of defaults and behavior.
The most important change in the pre-release is that all LazyFrame queries now run on the streaming engine by default. According to the project's announcement at pola.rs, that change is meant to improve memory usage and performance for a broad range of workloads. The team said casual users should see large gains, and it described the streaming engine as potentially several times faster on aggregate. Users who need the older in-memory default can still opt into it by setting engine affinity.
The release is not only about speed. Polars 2.0 also changes how the library handles row order in operations such as joins, group-by and unpivot. Because streaming execution does not guarantee row order in every case, users who require stable ordering must now opt in explicitly with maintain_order=True. That matters because it moves a subtle performance tradeoff into the open rather than leaving it hidden in the engine.
The announcement repeatedly emphasizes strictness. Polars wants errors to fail early, not after a long pipeline has already run, and the project says that is increasingly important for AI-assisted development as well. Agents can call collect_schema() to resolve types and catch schema-level mismatches before any data is materialized, giving them faster feedback while they iterate. The team also says it has made the library stricter in places where silent coercion could mask bugs.
One example is is_in comparisons across mismatched types. Before 2.0, Polars could cast both sides to a common supertype even if that conversion was lossy. The announcement says that behavior could create false positives when a large integer is rounded by Float64 conversion. In 2.0, the same situation raises an error and asks users to cast explicitly if they really want that behavior.
Another change affects horizontal concatenation. Instead of silently padding with nulls when lengths differ, Polars now checks lengths and requires users to opt into padding with how="horizontal_extend". The broader theme is that the library is trying to make intention more visible in code, even when that means breaking older habits.
The pre-release also introduces new typed exceptions, AttributeRemovedError and ArgumentRemovedError, so code that reaches removed attributes, methods or parameters gets clearer feedback and more direct migration guidance. The post says much of the removed behavior had been deprecated for a long time, but it still provides a migration guide for users moving from earlier versions.
The team frames 2.0 as a platform for future work rather than a ceiling. The post points to plans for proper out-of-core support, a new IO-plugin design, a faster S3 reader, better SQL coverage, a cost-based planner, join reordering and removal of mmap to support a more fully asynchronous pipeline. Those items are not all shipping now, but they show where the project is headed after the release candidate.
For now, the practical message is straightforward: Polars 2.0rc1 is available, the streaming engine is becoming the default path for lazy queries, and developers with existing pipelines should expect stricter validation and some migration work before the final 2.0 release lands in the coming weeks.
