一条长久以来的行业惯性，正在被一则激进的行业檄文打破：博主 Eddie 撰文直言 Pandas 应当灭绝。理由简单粗暴：Pandas 单线程架构和严峻的内存放大问题，把成千上万原本只有几十 GB 负载的团队，过早逼上了 Spark、Snowflake 这种维护繁琐且账单昂贵的大数据梁山。
过去工程师习惯遵循一条线性路径：数据小用 Excel，长到几 GB 换 Pandas，一旦逼近几十 GB 遭遇频繁崩溃，就立刻重构进分布式数仓。然而硬件在垂直扩容，NVMe 固态硬盘与百 GB 内存早已成为普通机器标配，底层向量化引擎也在重写规则。当单机已经能吞吐百 GB 级别的中等数据，我们为分布式集群支付的高昂溢价，究竟解决了真实业务痛点，还是一场过度设计的算力早熟？
算力账本里的“中等数据”假象
在针对 10GB 规格 CSV 的 PDS-H 性能测试中，新一代引擎给出了近乎残酷的差距：以 Rust 编写的 Polars 流式执行耗时仅 3.89 秒，分析型嵌入式数据库 DuckDB 用时 5.87 秒，而 Pandas 整整耗时 365.71 秒。不仅速度落后 94 倍，在扩展到 100GB 负载时，Pandas 更因无法有效流式读取而直接耗尽内存退出。
为了证明绝大多数团队根本不需要分布式计算，Eddie 援引亚马逊在 2024 年 VLDB 发表的论文，通过对数据吞吐速度和单行体积做假设，推算出 Redshift 实例中 94.68% 的表小于 100GB，甚至 86.9% 的查询处理的数据都在 80GB 以下。
但这类推算抹去了关键的工程上下文。亚马逊原论文深入调查了 200 个预置型与 200 个 Serverless Redshift 实例在 3 个月内的运行轨迹，其统计基准其实是行数而非绝对存储字节数：生产环境中约 98% 的表少于 10 亿行，仅约 1.8% 的表突破 10 亿行大关。由于字段列数、嵌套数据及压缩算法千差万别，仅凭平均数倒推出的体积无法直接套用在每一个具体场景。
商业分析工具的宣传同样夹带立场。MotherDuck 创始人 Jordan Tigani 曾分析该数据指出，只有 0.03% 的查询扫描超过 10TB 数据，仅占总体运行耗时的 5.6%；全网只有约 5% 的数据库迈入其定义的 10TB 大数据门槛。但他所用的观察窗口是单次查询最大扫描量，既容易忽略常态下的大规模冷数据归档，也为了推广自身产品而刻意淡化了全局规模。
单机引擎的锋刃与暗礁
Polars 与 DuckDB 的脱颖而出，代表着分析计算对关系型数据库经典的流水线与列式内存布局的全面吸收。Polars 凭借 Rust 的无开销并发和惰性查询优化，把过滤条件下推（Predicate Pushdown），避免了无意义的全量载入；DuckDB 则把类似 SQLite 的开箱即用体验赋予分析场景，支持在几行 Python 代码中直接对本地文件执行向量化计算。
然而，在单机上顺畅跑通合成基准测试，绝不意味着能平替分布式体系。当数据跨过 100GB 门槛，测试环境的物理硬伤便会暴露。
来自 Coiled 与社区的多项测试揭示了真实短板：DuckDB 依靠默认约为 系统 RAM 80% 的阈值控制和外存溢出机制表现得最稳健，甚至能在 16GB 内存笔记本上借助磁盘落盘完成 50GB 聚合运算。但在遇到超高基数聚合或复杂阻塞算子时，依然存在用尽内存的风险。而 Polars 在执行大尺寸数据关联等不可流式算子时，面对 100GB 数据仍会触发内存崩溃。
跑分比拼的是理想状态下的瞬时吞吐，工程交付的底线则是不可中断的确定性。
- 风险.盲目用单机单进程引擎替代集群，极易在遇到高基数宽表关联、数据严重倾斜等不可流式算子时，因内存不足导致整条离线流水线直接中断。
生产环境不是单机跑分场
为什么即使面对单机向量化引擎的巨大成本反差，企业依然心甘情愿为分布式系统埋单？
PySpark 在处理 10GB 数据时比新工具慢几十倍，原因在于单机运行时无法避开 JVM 虚拟机的初始化开销、多进程序列化损耗与执行器调度延迟。但分布式系统的设计初衷从来不是为了跑快单次聚合，而是在不可靠的机器网络上实现算子容错与失败重试。
天下熙熙，皆为利来。当数据规模不断上涨，单机任务失败一次意味着整个作业从零重跑，而在多节点集群上，Spark 的任务级重试机制能把崩溃约束在局部节点。再加上企业所需的细粒度列级权限、多租户查询排队机制、事务一致性与审计合规保障，单机脚本哪怕性能再强，也无法替代生产基础设施的综合治理能力。
- 建议.当团队日常分析处于 10GB 到 100GB 这一中等区间时，应坚决引入 Polars 或 DuckDB 替代老旧的 Pandas 流程；但当系统涉及高并发写入、关键业务容错与组织级权限协同，集群数仓依旧是不可逾越的底线。
Pandas 或许正在老去，但技术的交替从来不是非生即死的零和清算。认清中等数据的算力真相，是为了拒绝过早陷入昂贵的分布式军备竞赛，而不是在另一个轻量化神话里盲目自封。