本文へ
ハクソク

世界を動かす技術を、日本語で。

Polars 2.0のリリース

元記事: 原文(pola.rs)

概要

Polars 2.0の主な新機能とパフォーマンス改善について解説。 SQLサポートの強化と高速化によるベンチマーク優位性。 ストリーミングエンジン・アウト・オブ・コア処理のデフォルト化。 新しいMap型データ型の導入と型チェックの厳格化。 今後のロードマップとアップグレードサポートの案内。

Polars 2.0の新機能とハイライト

  • Polars 2.0 リリース、主な目的は パフォーマンス向上 と 新機能追加
  • アウト・オブ・コア（ディスクスピル） 対応の初期バージョンを標準搭載
  • SQLサポート を大幅強化、 パフォーマンス改善 と合わせて DuckDBやDataFusionを上回るベンチマーク結果
  • Map型（Arrow MapType） を正式サポート、Pythonの辞書型のような使い勝手
  • 型チェックと明示性 の強化、バグの早期発見やAIによるクエリ自動生成の効率化

パフォーマンスとSQLサポートの進化

  • SQLをファーストクラス市民 として扱う方針を明確化
  • クエリ最適化 の強化（joinの順序最適化、共通部分プランの排除、動的述語・ブルームフィルタの実装）
  • TPC-H/TPC-DSベンチマーク で Polars SQL が他エンジンより高速
    • c7a.4xlarge（16 vCPU, 32GB） と c7a.metal（192 vCPU, 384GB） で検証
    • 全クエリ5回実行 し最速値で比較、フェアな条件設定
  • Polarsは全ベンチマークで最速 （一部例外除く）
  • スレッド数増加時のオーバーヘッド が小規模データで影響、今後修正予定
  • ベンチマーク再現用リポジトリ 公開：https://github.com/pola-rs/polars-2.0-benchmark

ストリーミングエンジンとアウト・オブ・コア処理のデフォルト化

  • LazyFrameのcollect呼び出し でデフォルトが ストリーミングエンジン に変更
    • メモリ効率とパフォーマンス大幅向上
    • join/group_by/unpivot等で順序維持が必要な場合は maintain_order=Trueを指定
  • アウト・オブ・コア処理 は RAMの約80% で自動的にスピル開始
    • デフォルトのディスク使用上限は64GB
    • sort、ウィンドウ関数、多くの式 でディスクスピル対応
    • 今後はjoinやgroup-byにも対応予定

新しいMap型データ型の導入

  • Arrow MapType を Polars Map dtype として正式サポート
    • Python辞書型 のようなキー・値マッピング
    • 従来：List(Struct({"key": ..., "value": ...}))として読込
    • 2.0以降：map[str, i64]型として扱い、専用の式やメソッドを利用可能
  • 主なメソッド例
    • キーによる値取得 （固定値・他カラム参照）
    • キー存在判定
    • 要素数・キー一覧・値一覧取得

Polarsの厳格化とAI時代の開発効率

  • エラーは早期に検出 し、暗黙的な型変換・データ不一致は原則禁止
  • collect_schema() によるクエリ構造の事前検証が可能
    • AIエージェントや人間の高速な開発サイクルを支援
  • データ依存のエラーも厳格に検出 し、予期しない挙動を防止

今後の展望とサポート

  • 今後はさらにアウト・オブ・コア機能や大規模CPU対応を強化
  • Polars Cloudで最速の分散エンジンを目指す
  • GeoPolars開発中、今後情報公開予定
  • 問題報告はGitHub Issuesへ ：https://github.com/pola-rs/polars/issues
  • バージョン2.0への移行ガイド も公開中

ベンチマーク補足・スケーリング

  • Polarsは大規模データ/コア数増加で高いスケーリング性能
    • SF100（TPC-H）：16→192 vCPUで3.8倍高速
    • DuckDB 1.5.6：3.2倍、DataFusion：1.7倍
    • 小規模データでは追加コアの効果が限定的
  • ベンチマークは正式TPC-H/TPC-DS仕様準拠ではない点に注意

Polars 2.0 は、 SQLサポート強化・新しいMap型・厳格な型チェック・大規模データ耐性 を備えた、次世代のデータフレームエンジンへの進化を遂げました。

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

duckdbがもうすぐ2.0.0をリリースするっていう偶然かな？ :)

└

何か競争してるの？

└

実際、そうなんだ。2.0の計画はかなり前からしてたんだよね。1.0をリリースしたときに1.xからすぐに移行すると言ってたけど、結局1.xにずっと居座ってた。ざっと見た感じ、最初のPRは6月に2.0ブランチにマージされたよ。2026-06-17T21:27:51Z #27993 chore: pl.col(...)をセレクタに強制変換するのをやめる ... 2026-06-18T14:19:26Z #27996 chore!: マルチシードハッシュAPIをシングルシードに置き換える 2026-06-19T07:05:11Z #27991 chore(python!): Expr.flatten関数を削除する

一番気になるのは、古いeager-vs-lazyのバグがちゃんと修正されたかどうかだな。ループ内の余計なcollect()がクエリプランをぶっ壊してたから。

今日知ったんだけど、PolarsがSQLをサポートしてるんだ。すごいね。

└

最初のリリースからそうだったけど、限られてたね。今はダックDBと真っ向勝負したいみたい。

└

いつになったらポーラーズは基本的にインメモリデータベースだと言えるのかな？（本気の質問）

トレンドはあまり追ってないけど、PolarsはPandasの完全な代替になったの？どっちが使いやすいケースってあるの？

└

自分の理解では、Polarsは速いし、外部ソリューションを使わずにスケールするのが得意だし、APIも良いし、+Rustだね。Pandasは、ほとんどの人が使ってるものを使いたいなら勝ちだと思う。多分、使い込むときにぶつかる小さなことに対するヘルパーやレシピがもっと揃ってるけど、LLMの時代ではそれは小さいことだと思う。

└

ポーラーズは実質的に99.9%のケースでパンダスの完全な代替になるよ。唯一の例外は地理空間データを扱ってる場合かな。まだ「ジオポーラーズ」みたいな、よく使われる「ジオパンダス」の代わりはないけど、ジオポーラーズはまだ開発中で、最終的には本番環境でも使えるようになるはず。

└

最近のPython Bytesポッドキャストからの情報（https://pythonbytes.fm/episodes/show/496/a-lake-house-in-sea...） > 10億行チャレンジのベンチマーク：パンダスは4分28秒、ポーラーズは5.04秒、ダックDBは5.19秒だった — ダックDBはメモリも19倍少なく使った。PythonとRustの速度比較：比べ物にならないよ。（上のエピソードのトランスクリプトには「パンダスは絶滅すべき」というタイトルのブログ記事へのリンクがあるよ）

└

パンダスからポーラーズへのGFQLの完全な移植ができたよ。データフレーム上でのサイファーグラフクエリを、CPUとGPUモード両方で行って、すごいスピードアップを達成したんだ。https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra... すごい印象的だった！

Hacker Newsで議論の続きを見る