2026年9月3日の出来事として、PolarsチームはPolars 2.0の最初のリリース候補版を公開した。このメジャーバージョンは、機能を披露するというより、デフォルト設定と動作をリセットすることを意図したものだ。

このプレリリースで最も重要な変更は、すべてのLazyFrameクエリがデフォルトでストリーミングエンジン上で実行されるようになったことだ。pola.rsに掲載されたプロジェクトの発表によると、この変更は幅広いワークロードでメモリー使用量とパフォーマンスを改善することを目的としている。チームは、一般ユーザーにも大幅な改善が見込まれるとし、ストリーミングエンジンは全体として数倍高速になる可能性があると説明した。従来のインメモリー方式をデフォルトとして必要とするユーザーは、エンジン・アフィニティーを設定することで、引き続きその方式を選択できる。

今回のリリースは速度だけを目的としたものではない。Polars 2.0では、結合、グループ化、アンピボットなどの処理における行順序の扱いも変更される。ストリーミング実行では、すべての場合に行順序が保証されるわけではないため、安定した順序を必要とするユーザーは、今後はmaintain_order=Trueを指定して明示的に有効化しなければならない。これは、微妙なパフォーマンス上のトレードオフをエンジン内部に隠したままにせず、表面化させるため重要な変更だ。

発表では、厳格性が繰り返し強調されている。Polarsは、長いパイプラインがすでに実行された後ではなく、早い段階でエラーにより失敗させることを目指しており、プロジェクトによれば、これはAI支援による開発でもますます重要になっている。エージェントはcollect_schema()を呼び出して型を解決し、データが実体化される前にスキーマレベルの不一致を検出できるため、反復作業中により迅速なフィードバックを得られる。チームはまた、暗黙の型変換がバグを覆い隠しかねない部分で、ライブラリをより厳格にしたとしている。

その一例が、型の一致しない値同士に対するis_in比較だ。2.0より前のPolarsでは、変換により情報が失われる場合でも、両辺を共通の上位型へキャストすることがあった。発表によると、この動作では、大きな整数がFloat64への変換によって丸められた際に偽陽性が生じる可能性があった。2.0では、同じ状況でエラーが発生し、その動作を本当に望む場合は明示的にキャストするようユーザーに求める。

もう一つの変更は水平方向の連結に影響する。長さが異なる場合に暗黙のうちにnullで埋めるのではなく、Polarsは長さを確認し、パディングを行うにはhow="horizontal_extend"を指定して明示的に有効化するようユーザーに求める。より大きなテーマは、古い習慣を破ることになっても、コード内で意図がより明確に見えるようにするというライブラリの試みだ。

このプレリリースでは、新たな型付き例外であるAttributeRemovedErrorとArgumentRemovedErrorも導入される。これにより、削除された属性、メソッド、パラメーターにコードがアクセスした場合、より明確なフィードバックと直接的な移行案内が得られる。投稿によると、削除された動作の多くはかなり以前から非推奨となっていたが、それでも旧バージョンから移行するユーザー向けに移行ガイドが用意されている。

チームは2.0を到達点ではなく、今後の作業に向けた基盤と位置付けている。投稿では、本格的なアウト・オブ・コア対応、新たなIOプラグイン設計、より高速なS3リーダー、SQL対応範囲の拡大、コストベースのプランナー、結合順序の最適化、そしてより完全な非同期パイプラインに対応するためのmmap廃止といった計画が挙げられている。これらすべてが現時点で提供されるわけではないが、リリース候補版以降にプロジェクトが向かう方向を示している。

現時点での実務的なメッセージは明快だ。Polars 2.0rc1はすでに利用可能で、ストリーミングエンジンが遅延クエリのデフォルトの実行経路になりつつあり、既存のパイプラインを持つ開発者は、今後数週間で正式な2.0がリリースされるまでに、より厳格な検証と一定の移行作業を見込む必要がある。