你要整理一张塞不进电脑内存的大表。过去，程序更像搬家：先把东西全搬进屋，再开始分类；屋子不够大，任务就可能卡住。Polars 2.0 想把流程改成流水线：数据分批进来，能计算的尽早计算，内存紧张时再把部分中间结果暂存到磁盘。值得关注的不是多了一个高级选项，而是这条路径现在成了默认选择。
Polars 是一个处理二维表格数据的分析引擎。这里的 DataFrame，可以理解为一张带列名和数据类型、能由程序操作的表格。数据团队常用它清洗日志、连接数据集和汇总统计。关于 2.0 的发布与功能变化，目前材料均来自参与 Polars 的作者及项目官方渠道，尚无独立实测交叉验证。
流式引擎正式走到前台
据参与项目的 Ritchie Vink 在发布帖中的介绍，Python Polars 2.0 已正式发布，并将 streaming engine——流式执行引擎——设为默认执行引擎。它把数据分批读入，尽早筛选、聚合或产出结果，不必总把整张表一次性装进内存。
“默认”是这次变化的关键。以前，流式处理更像用户主动选择的一种执行方式；现在，更多普通查询会自动走这条路径。对数据团队来说，这会直接改变日常使用习惯：他们不必先判断是否应该切换引擎，系统会优先按分批处理的思路执行。
但默认启用不等于旧引擎已经被完全移除。现有材料只说明流式引擎成为默认选项，不能进一步推断所有查询都能流式执行，或旧路径已经消失。
内存装不下，也可以继续算
2.0 还加入了初步的 out-of-core 支持。这个词指的是：计算时不要求原始数据和全部中间结果同时待在内存里。其具体手段是 spill to disk，也就是内存不足时，先把部分中间数据暂存到磁盘。
这让 Polars 开始跨过一个重要边界：可处理的数据规模不再完全受机器内存容量约束。不过，“初步支持”需要按字面理解。官方材料没有说明它已经覆盖全部算子或所有查询场景。磁盘读写通常也比内存访问慢，所以它解决的是“能不能完成”，不保证“仍然一样快”。
SQL 不再只是附带入口
另一项方向性变化，是 SQL 被提升为 first-class citizen，也就是“一等公民”。SQL 是一种声明“想得到什么结果”的表格查询语言。熟悉数据仓库的分析师可以用它表达筛选、连接和聚合，而不必把所有工作重写成 Python 表达式。
据 Polars 官方文档与博客，项目没有为 SQL 另造一套执行器。SQL 查询会先被翻译成 Polars expressions——Polars 内部描述数据操作的表达式——再交给同一个查询优化器和执行引擎。换句话说，SQL 不只是包在外面的一层方便语法，而是被接入了 Polars 的核心计算流程。
这件事的意义不只在于“又支持一种写法”。当 SQL 与 DataFrame 共用底层能力，数据分析师和 Python 工程师可以使用各自熟悉的入口，同时依赖同一套优化与执行机制。团队采用 Polars 的门槛因此可能降低。
一次清理，为何变成大版本
Vink 称，2.0 清理了多项历史设计，其中包括团队后来视为错误的旧决定。官方博客还提到，这个版本原本只打算做一次小而平淡的整理；开发过程中，默认流式引擎、初步磁盘溢写、Map 数据类型和多项性能改进陆续加入，最终超出了最初范围。
Map 是新增的数据类型。现有材料没有进一步解释它的语义、适用场景和接口细节，因此不宜仅凭名称展开推断。项目也发布了 migration guide——迁移指南——帮助现有用户处理升级时的兼容变化。既然大版本主动清理历史设计，升级前查看迁移指南比直接替换版本更稳妥。
为什么值得关注？
Polars 1.0 在 2024 年发布时，官方将其描述为内存引擎和 API 达到“production ready”，即可以投入生产使用的节点。两年后的 2.0，则把重点从“内存里跑得好”推向“默认分批执行，并开始处理超出内存的数据”。这不是简单增加几个函数，而是在调整引擎面对数据规模时的默认策略。
团队还表示，他们认为 Polars 已是单节点上最快的分析型 SQL 引擎之一。但这只是项目方的判断，措辞本身也是“we think”。目前材料没有提供独立基准测试；此类排名还高度依赖数据集、硬件、查询类型、并发设置和对手版本，因此不能当作已经证实的结论。
局限与未知
- 所有发布信息都来自项目相关人士或官方材料，尚缺软件包记录和第三方测试的独立交叉验证。
- 初步 out-of-core 支持覆盖哪些操作、在什么条件下触发，现有材料没有披露。
- “多项性能改进”及单节点 SQL 性能主张缺少可据此详述的独立数据。