Polars 開發團隊於 2026 年 10 月 6 日發布 Polars 2.0 版本。儘管團隊表示並非刻意打造大型功能版本，但此次更新仍包含多項重大改進，包括初步的離線核心（out-of-core，即磁碟溢出 spill-to-disk）支援、核心效能優化、一等公民（first class）SQL 支援、新的 Map 資料型別，以及更嚴格的資料型別檢查以提升反饋速度。
在 SQL 與效能方面，Polars 2.0 將 SQL 視為一等公民，並透過優化器改進（如 join 重排序、共同子計畫消除、動態謂詞/布隆過濾器）提升效能。官方發布了基於 TPC-H 和 TPC-DS 衍生資料的基準測試結果，比較對象包括 DuckDB 1.5.6、DuckDB 2.0 alpha 及 DataFusion 54.0.0。測試環境為 c7a.4xlarge（16 vCPUs, 32GB RAM）和 c7a.metal（192 vCPUs, 384GB RAM），每個查詢執行 5 次取最佳值。結果顯示，Polars 預設設定在除一個基準外的所有測試中均為最快。然而，Polars 在擴展至 192 執行緒時存在固定開銷，影響小資料查詢；若限制為 32 核心，則在所有基準中表現具競爭力或領先。團隊已診斷出原因並預計在下一版本修復。此外，在 SF100 規模下，Polars 從 16 核擴展到 192 核時，TPC-H 速度提升 3.8 倍，TPC-DS 提升 2.2 倍，優於 DuckDB 1.5.6 的 3.2 倍和 1.9 倍。但在 SF10 規模下，額外核心對 Polars 預設設定無幫助，甚至導致 TPC-DS 變慢。
在架構變更方面，LazyFrame 的 collect 操作現在預設使用串流引擎，這導致大多數查詢的記憶體和效能大幅改善。由於串流引擎預設不保證某些操作（如 join, group_by, unpivot）的行順序，若需保持順序，必須設定 maintain_order=True。離線核心處理現已預設啟用，當記憶體使用率約達 80% 時開始將資料溢出至磁碟，預設磁碟預算為 64GB。目前支援離線核心的操作包括排序、視窗函數及許多表達式，未來將擴展至 join 和 group-by。
新功能包括直接支援 Arrow MapType 作為 Polars 的 Map 資料型別，提供類似 Python 字典的鍵值對操作，並支援鍵查找、迭代等專用表達式。此外，Polars 採取更嚴格的策略，強調快速失敗（fail fast），隱式行為改為選擇加入（opt-in），以減少隱藏錯誤。這對於 AI 驅動開發尤為重要，因為代理（Agents）可透過 collect_schema() 早期驗證查詢結構，無需實際化資料即可捕捉架構層級的不匹配，從而加快迭代速度。
事件背景
Polars 是一個用 Rust 編寫的高效能 DataFrame 函式庫。TPC-H 和 TPC-DS 是業界標準的決策支援系統基準測試。官方聲明指出，這些基準測試結果衍生自 TPC-H 和 TPC-DS，但不符合官方 TPC 基準測試規範，因此結果不可與已發布的官方 TPC 結果直接比較。
社群觀察
社群討論中，有使用者推薦 Polars 作為 Pandas 的替代品，認為其查詢規劃器功能強大。然而，也有具備基準測試經驗的用戶提醒，不應將此類部落格文章解讀為「資料庫 A 比資料庫 B 快 X%」，因為影響因素眾多，應視為開發團隊針對特定工作負載的效能改進。另有用戶詢問 Polars 是否已完全取代 Pandas，以及兩者各自的適用場景。部分用戶表示在新專案中將考慮使用 DuckDB、Polars 或 PyArrow。還有用戶指出在之前的使用中，Polars 的記憶體使用量高於 DuckDB，並猜測串流引擎可能解決此問題，建議基準測試應包含記憶體使用量的比較。
