The engine default is part of your API.
Polars 2.0 now uses its streaming engine when a lazy query calls collect(). The release says this improves memory use and performance on most queries. It also says that operations such as joins, group-bys, and unpivots do not promise row order unless the caller requests it.[1]
A pipeline can return the same rows and still break a snapshot, export, or downstream diff. If order matters to a consumer, name the sort key or use the documented order-preserving option. Do not rely on an old engine's accidental sequence.
A faster answer in a different order is a different answer when order is observable.
Spill-to-disk needs a disk contract.
The initial out-of-core support starts spilling near 80 percent of RAM and uses a default disk budget of 64 GB. The release names sort, window functions, and many expressions as supported operations. Out-of-core joins and group-bys remain planned work.[1]
That makes an upgrade review a placement review too. Record the temporary-storage path, free-space floor, quota, cleanup behavior, and failure you expect when the budget is exhausted. A query that avoids an out-of-memory crash can still fill the wrong volume.
Strict types shorten the repair loop.
Polars says 2.0 removes or tightens several implicit casts. The upgrade guide lists strict membership checks, stricter concatenation, direct Map loading, decimal changes, and rejected casts that used to pass.[2]
The lazy API exposes collect_schema() so a caller can resolve column names and data types without materializing a result. Polars documents that schema checks happen before data processing when a lazy query executes.[3] That is a useful agent loop: draft the expression, inspect the schema, then spend data and compute on the run.
The benchmark is a lead, not your verdict.
The release reports wins on TPC-H- and TPC-DS-derived workloads across two AWS machine sizes. It publishes machine details, engine versions, excluded failures, raw timings, and a reproduction repository. The authors also flag overhead at 192 threads on smaller data and say the results are not official TPC results.[1][4]
That is good release evidence. It does not tell you whether your sort keys, nulls, user-defined functions, storage, and concurrency improve. Keep one representative old-version baseline and one 2.0 candidate run. Compare output first, then peak memory, spill bytes, and elapsed time.
The package ran. The production workload did not.
We installed the published polars==2.0.0 Python package in an isolated environment. It reported version 2.0.0, resolved a lazy schema, collected a small frame, and raised InvalidOperationError on a strict string-to-integer cast containing bad.
That smoke check proves the package exists and those narrow paths execute here. It does not measure spill behavior, row-order changes, benchmark speed, or compatibility with a real pipeline.