The default argument in `collect()` is still `engine="auto"`. What changed is what `auto` resolves to: the streaming engine for lazy queries, where it used to be the in-memory engine [1]. The call site itself is unchanged, and no error gets raised. The pre-2.0 row order for `group_by`, `join` and `unpivot` was never a documented contract, and the streaming engine does not offer one either [5]. That governs how you fix it. The guide's own `unpivot` example comes back grouped per index key rather than per variable, and the guide then says the order shown is not guaranteed, only that it is no longer the pre-2.0 order [7]. Re-recording a snapshot test against the new output does not pin the order down. The two supported fixes are an explicit `.sort(pl.all())` or `maintain_order` where the operation supports it, as in `join(..., maintain_order="left")` [8].
Some of the blast radius is narrower than it looks. `sink_*` was already dispatched to the streaming engine regardless of `engine`, so file-writing pipelines have had these semantics all along [3]. Eager `DataFrame` operations still resolve `auto` to in-memory internally [2]. The wider part is SQL: `pl.sql(..., eager=True)` and `SQLContext.execute(eager=True)` used to collect through the in-memory engine and now go through `LazyFrame.collect()`, so a query string with no engine argument anywhere in sight picks up the new default [9].
Column order breaks in a second, unrelated place. `pl.read_csv` is now dispatched to `pl.scan_csv(...).collect()`, gaining six scan parameters including `with_column_names` and `credential_provider`, and losing `n_threads`, `batch_size`, `sample_size` and `rechunk` [10]. Its behaviour now matches `scan_csv` exactly, so `columns=[2, 1, 3]` returns `['c', 'b', 'd']` where it used to return the sorted `['b', 'c', 'd']`, and a `schema_overrides` list must cover every column in the file or raise `SchemaError` [11]. That failure now surfaces at the boundary rather than downstream.
The strictness work is the part of this release I would ship unchanged. Polars' example is a flagged-account check: `flagged_ids` arrives from JSON as `Float64` holding 9007199254740992.0, the user ID is the `Int64` 9007199254740993, and pre-2.0 coercion to the common supertype rounded the ID down and returned a false positive [12]. The ID sits exactly one above 2^53, the largest integer float64 represents exactly [13]. In 2.0 that raises `InvalidOperationError` [12]. Horizontal `concat` now checks lengths rather than filling the short frame with nulls [14]. Both changes convert a silent wrong answer into a stack trace, which is the trade the row-order default makes in the opposite direction.
Polars expects the streaming engine to be easily 5x faster in aggregate [15]. That is a number about their aggregate. For it to transfer, your work has to be the kind that batches, which is what the streaming engine does instead of processing all data at once [16]: a working set at or past memory, or scans that stream, or joins you are willing to leave unordered. Every `maintain_order` you add pays some of it back, and The New Stack notes the speed cost without quantifying it [17].
So the sequence I would use is affinity first. Set `POLARS_ENGINE_AFFINITY=in-memory`, absorb the 2.0 API changes, get green, then move queries onto streaming one at a time as each order assumption is removed or made explicit [18]. That turns one upgrade into two changes with separate blast radii. The announcement says the team hopes 2.0 is a boring experience [19]; the red danger box in the migration guide is doing a fair amount of work to keep that promise [4].</body_markdown> </invoke>
