編按：本文綜合整理自 Polars 官方部落格原文（Ritchie Vink，2026-10-06）、Polars 2.0 預發布公告（2026-09-02）、官方 TPC-H/TPC-DS 基準測試倉庫、Hacker News 討論串，並加入 Siami 編輯部觀點與分析。
Polars 創辦人 Ritchie Vink 於 2026 年 10 月 6 日正式發布 Polars 2.0，這是這個用 Rust 寫成的 DataFrame 查詢引擎問世以來最重要的一次主版本升級。雖然團隊強調「不希望這是一個大改版」，但實際內容遠比外界預期豐富：Out-of-Core（spill-to-disk）變成預設、SQL 成為一級公民、Polars 在官方 TPC-H/TPC-DS 基準測試中跑贏 DuckDB 1.5.6、DuckDB 2.0 alpha 與 DataFusion 54.0.0，並且首次加入對應 Arrow MapType 的 Polars Map dtype。
這次發布當天立刻登上 Hacker News 首頁，4 小時內累積超過 200 分、38 則討論，並有 Lobsters、Threads、Instagram、X 等多平台同步轉發。
五大重點功能
這次 2.0 的重點濃縮成五項：
- Out-of-Core（spill-to-disk）變預設：RAM 用到約 80% 自動把運算溢出到磁碟，預設磁碟預算 64GB
- Streaming engine 變預設：呼叫 LazyFrame.collect() 直接走 streaming，多數查詢約 5 倍加速
- SQL 變一級公民：JOIN 重排序、更強的 common subplan elimination、動態 predicate / bloom filter 全部就位
- TPC-H / TPC-DS 跑贏對手：在 c7a.4xlarge 與 c7a.metal 上領先 DuckDB 1.5.6、DuckDB 2.0 alpha、DataFusion 54.0.0
- 新 Map dtype 與更嚴格的型別檢查：對應 Arrow MapType，並且對 AI agent 開發更友善
Out-of-Core 與 Streaming Engine：對一般使用者最大的改變
Vink 在公告中特別強調，這次最大的實質影響其實是「對 casual data practitioners」最關鍵的兩項變更：streaming engine 與 out-of-core 變成預設。
Streaming engine 變成 LazyFrame 的預設。呼叫 .collect() 會直接走 streaming，多數查詢得到記憶體與效能的雙重改善。Vink 解釋：「這次主版本跳號的原因是，streaming engine 在某些操作（join、group_by、unpivot）下不再保證 row order。如果你的查詢需要可觀察的列順序，可以設 maintain_order=True 自行打開。」
Out-of-Core（spill-to-disk）自動啟用。當 RAM 使用達到約 80%，Polars 會自動把中間結果溢出到磁碟，預設磁碟預算 64GB。目前支援 out-of-core 的操作包含 sort、window functions 與多數 expressions；join 與 group_by 的 out-of-core 還在 roadmap 上。
對一般資料分析師的意義是：**過去需要手動切 batch、或者升級到 Spark / Dask 才能處理的「大於記憶體」工作負載，現在 Polars 2.0 直接幫你處理。**這對還在用 pandas、碰到 10GB+ 資料就要 swap 的團隊是巨大的生產力提升。
SQL 變一級公民：跟 DuckDB 正面對決
這次 2.0 的另一個戰略性變更是 SQL 的定位。Vink 寫道：「在 Polars 2.0，SQL 將成為 first class citizen。過去幾個月 Polars 的 SQL 覆蓋率大幅提升，現在我們要把這套引擎開放給更多 workload，包括 SQL。」
為此 Polars 2.0 對 optimizer 與 engine 做了大量改進：join reordering、更好的 common subplan elimination、動態 predicate 與 bloom filter。
最直接的證據是官方在 polars-2.0-benchmark 倉庫 公開的 TPC-H / TPC-DS 比較。測試條件如下：
- 對手版本：DuckDB 1.5.6、DuckDB 2.0 alpha (2.0.0.dev2610011535)、DataFusion 54.0.0
- 硬體：c7a.4xlarge（16 vCPUs, 32GB RAM）與 c7a.metal（192 vCPUs, 384GB RAM）
- 資料生成：tpcgen-cli parquet（commit 99bedae），儲存於 EBS
- 每個查詢跑 5 次取最佳值，60 秒 timeout
官方結論：預設 Polars 在幾乎所有基準測試中都是最快。Polars 的小資料查詢在 192 執行緒下有固定 overhead（限制為 32 核心時反而能贏），這個 scaling 問題團隊已診斷出原因，預計下個版本修復。
Polars 在 TPC-H 從 16 核升到 192 核時達到 3.8 倍加速（用 sum 計算），TPC-DS 則是 2.2 倍；對比 DuckDB 1.5.6 是 3.2x / 1.9x，DuckDB 2.0 alpha 是 2.2x / 1.5x，DataFusion 是 1.7x / 1.0x。
新 Map dtype：Polars 與 Arrow 生態的深度整合
2.0 把 Arrow 的 MapType 直接升級為 Polars 的 Map dtype。在 2.0 之前，Arrow MapType 在 Polars 裡被讀成 List(Struct({"key": ..., "value": ...}))，型別系統不一致。2.0 之後 Map 是一等公民，並有專屬表達式：
df = pl.DataFrame({
"user": ["alice", "bob", "carol"],
"scores": pl.Series(
[{"math": 90, "art": 75}, {"math": 60}, {}],
dtype=pl.Map(pl.String, pl.Int64),
),
"subject": ["art", "art", "math"],
})
df.select(
"user",
pl.col("scores").map.get("math").alias("math"),
pl.col("scores").map.get(pl.col("subject")).alias("by_subject"),
pl.col("scores").map.contains_key("art").alias("has_art"),
pl.col("scores").map.len().alias("n"),
pl.col("scores").map.keys().alias("keys"),
pl.col("scores").map.values().alias("values"),
)對使用者最直接的好處是：key 查找、迭代 values、dictionary-like 操作的效能與表達力都會更好。Map 也是 JSON-like 資料、半結構化資料進入 Polars 管線的更自然接口。
為什麼這件事重要
Polars 2.0 的發布表面上看是「DataFrame 函式庫的版本升級」，但 Siami 認為它有三個層面的深遠影響：
第一，這是開源 DataFrame 棧與商業資料庫棧正式交鋒的分水嶺。
過去兩年，企業處理「中量級資料分析」（10GB - 1TB）的選擇是 Spark、Dask 或者 Snowflake / BigQuery。但這些選項的成本與複雜度都很高：Spark 需要叢集管理，Dask 對一般工程師門檻仍高，雲端倉儲則是按查詢計費。Polars 2.0 的意義在於：單機 out-of-core + streaming + 領先業界的 SQL 效能意味著 10GB - 1TB 等級的工作負載，現在可以用一個 pip install 處理，不需要任何叢集。這對中小型資料團隊是巨大的成本與複雜度下降。
第二，「對 AI agent 開發更友善」的設計哲學，是這個版本最被低估的部分。
Vink 在文中特別提到：「隨著 AI 驅動開發的興起，這種嚴格性變得更有價值。Agent 可以透過呼叫 collect_schema() 提早驗證查詢結構，在不物化任何資料的情況下抓出型別層級的不一致。這確保快速回饋，讓 agent 與人類都能更快迭代。」
這不是行銷話術。collect_schema() 在 2.0 變成正式 API，agent 可以先檢查 schema 是否對得上再決定要不要執行查詢。對 LLM-based 資料分析 agent（例如 PandasAI、LangChain pandas agent）而言，這是 workflow 變革：agent 可以在「不花錢跑查詢」的情況下驗證查詢計畫是否合法，這對 LLM 成本控制意義重大。
第三，Polars 與 DuckDB 的正面對決代表「DataFrame 與 SQL 引擎的界線正在消失」。
過去 DataFrame 函式庫（pandas、Polars）與 SQL 引擎（PostgreSQL、DuckDB、ClickHouse）是兩條平行產品線。Polars 2.0 把 SQL 拉到一級公民、DuckDB 同時強化 DataFrame API，這代表兩者都認為「一套引擎同時吃 DataFrame 與 SQL」是正確的最終形態。對開發者而言，未來選 Polars 或 DuckDB 會比今天更難，因為它們解決的問題集合越來越像。
質疑與挑戰
Siami 認為這次發布有幾個值得質疑的點，整理如下：
質疑一：基準測試是不是 cherry-picked？
官方 TPC-H / TPC-DS 測試在預設 Polars 上是「最快」，但 HN 上有用戶反映「DataFusion 在我的工作負載下其實互有領先」。社群媒體（Threads、Instagram）的轉發也以正面報導為主。Polars 自己的基準測試用的是「自己的硬體選擇 + 自己的 query 生成方式 + 自己的 row group 設定」，這跟獨立基準測試（如 Ibis Project 的 DuckDB/DataFusion/Polars 比較、Coiled 的 TPC-H 比較）的結果會有些差異。結論：領先是真的，但領先幅度需要打折看。
質疑二：對 192 核心的 scaling 問題沒解決。
官方承認 Polars 在 192 核心下有固定 overhead，限制為 32 核心反而能贏。這個 scaling 問題對未來「Polars Cloud」（他們正在做的分散式產品）至關重要。Vink 承諾下個版本會修，但這代表現在用 32+ 核心機器的使用者要嘛手動限制執行緒數、要嘛等修。
質疑三：版本升級破壞性。
「Polars 2.0 預設不再保證 row order」這件事對既有使用者是 breaking change。雖然可以用 maintain_order=True 退回，但官方文件警告：「A user that has been using the maintain_order keyword to guarantee order may notice that the default for the parameter is now False everywhere and may be surprised that their queries are now faster.」
對 production pipeline 來說，這需要完整的回歸測試才能升級。Reddit r/Python 已經有人在問「升級踩坑經驗」。Siami 建議：production 環境不要急著升級，先在小專案或 staging 跑一輪回歸測試。
數據解讀
| 數字 | 來源 | 意義 |
|---|---|---|
| 3.8x / 2.2x | Polars 官方 TPC-H / TPC-DS 測試（16→192 核） | Polars 在大資料規模的 scaling 倍率 |
| 5x | 預發布公告 (2026-09-02) | Streaming engine 對 in-memory engine 的平均加速 |
| 80% | Polars 2.0 預設 | Out-of-Core 開始 spill 到磁碟的 RAM 門檻 |
| 64GB | Polars 2.0 預設 | 預設磁碟預算上限 |
| 80 | Polars 開發團隊 | 核心貢獻者規模（含外部） |
| 28K+ | GitHub stars | 社群規模（截至 2026-10） |
| 306 | Hacker News 點數 | 發布 12 小時內累積 |
| 1,176 | Lobsters / Threads / X 轉發估算 | 跨平台總曝光 |
結語
Polars 2.0 表面上是「DataFrame 函式庫的版本升級」，實際上是 Rust 開源陣營對單機資料處理市場的全面接管宣告。對還在用 pandas 處理 5GB+ 資料的團隊，這次升級提供了零叢集成本的現代化路徑；對已經在用 Polars 的團隊，2.0 帶來的 out-of-core 與 SQL 強化讓你可以正式把 DuckDB 從你的 stack 裡拿掉。
Siami 將持續追蹤：（1）DuckDB 2.0 正式發布後的正面比較；（2）Polars Cloud 分散式引擎的進度；（3）GeoPolars（地理空間功能）的進展；（4）社群對「row order 不再預設保證」這個 breaking change 的回饋。
對 Python 資料棧的使用者，Siami 的建議是：如果你已經在用 Polars，現在就升級 2.0 體驗 streaming + out-of-core；**如果你還在 pandas + Spark 的組合，先把 pandas 換成 Polars，Spark 留給真的需要叢集的工作負載。**這可能是過去三年 Python 資料棧最大的單一升級。
網友熱門留言 (8)