polars 官方 github 发布页已经上线了 python polars 2.0.0-rc.1 预发布版本，排在第一条的破坏性改动，就是把 sql 的默认引擎直接改成了流引擎。这个变动会直接影响所有用 sqlcontext 或者 sql 层处理查询的开发者，默认执行路径变了之后，之前的查询计划、资源占用表现，还有不少边界场景的行为都得全部重新验证。
来源：Polars 官方 GitHub Releases
同一份 2.0.0-rc.1 的更新日志里，还列出了一大堆性能优化和功能增强项：包括 Iceberg 接收器可以复用原生元数据、SQL 的 exists 谓词会下推到子查询执行前、基础类型的 group-by 聚合结果直接收集为单个数据块、优化器会按成本判断要不要保留缓存节点、可以基于扫描信息做 join 重排，同时开放了 Iceberg 接收器的写入配置选项，支持分片 Iceberg 接收器等等。看得出来这次 2.0 预发布的核心方向，全放在 SQL、Iceberg、执行计划和分布式/远程执行相关能力的打磨上。
来源：Polars 官方文档
预发布版本绝对不能没做测试就直接替换生产环境的依赖，但它已经把 Polars 后续大版本的调整方向摆得很清楚：SQL 层会进一步往流执行靠拢，查询优化能力和 Iceberg 数据湖相关的特性还会持续强化。如果你们团队生产环境已经在依赖 Polars SQL 或者 Iceberg 接收器，最好尽早安排兼容性测试，重点留意默认引擎切换、join 重排、谓词下推和缓存策略改动可能带来的结果偏差或者性能波动。
从 Polars 过往的发布记录能看出来，这个项目更新节奏很快，大量改动都集中在懒加载引擎、SQL、云服务、Iceberg、Parquet 和执行计划层面。数据团队做升级验证的时候，别只跑几个简单的 DataFrame 示例就完事，得覆盖真实业务查询、各类文件扫描、分组聚合、join 操作、SQLContext、云存储读写还有流执行全路径，才能发现默认引擎或者优化器改动带来的隐性差异。
现在官方文档已经把 LazyFrame、SQL、API 参考和云/本地部署的发布说明分开维护，也足以说明 Polars 早就不是单纯的单机 DataFrame 库了。大家选版本的时候，要注意区分 Python 版 Polars、Rust 版 Polars、Polars 云服务和各类预发布版本；生产环境通常优先选稳定补丁版，2.0.0-rc.1 这类预发布包只适合用来提前做兼容性演练。
由于 Polars 的同一个版本往往同时包含废弃接口、性能优化、功能增强和 bug 修复，升级过程里一定要完整保留所有 warning 输出。官方发布页里附的 PR 编号也能帮团队快速定位具体改动的出处，如果升级后发现查询结果、执行计划或者内存峰值出现异常，直接去对应发布日志条目和 API 文档核对原因就好。
信源说明：本文内容整理自 Polars 官方 GitHub Releases 中 Python Polars 2.0.0-rc.1 的更新说明，以及 Polars 官方文档首页；预发布版本的相关行为仍有可能在正式版上线前调整。
