SQLite还在称王，DuckDB却偷家，本地分析要变天。
很多人说都2025年了，谁还拿SQLite做分析？这话对了一半。拿行存数据库跑聚合确实别扭，但不是SQLite没用，而是它管的是在线事务，DuckDB管的是分析，分工多过替代。本文只说三件事：它快在哪，抢了谁的位置，什么时候不该用。
DuckDB常被叫“分析型SQLite”。这名字来自四个点：进程内、嵌入式、零配置、单文件。它部署像SQLite，但内核不一样，SQLite是行存B树，DuckDB是列式存储。一句话，DuckDB像把ClickHouse的列式内核，塞进SQLite的壳里。
为什么行存做分析吃亏？比如查用户订单金额，表里二十列，只用两列，行存还是把二十列都搬进内存。带宽浪费了，CPU缓存也没法好好用。列存只读需要的列，差距从数据布局就开始了。
快不只是因为用了C++。它还有向量化执行，一次处理一批，比如两千多行，不是一行一行解释。再加多核并行聚合，性能来自布局和执行模型，不是语言标签。
DuckDB不是突然冒出来。2018年，Mark Raasveldt和Hannes Mühleisen在荷兰CWI启动了这个项目。2021年开源后，它靠直接查Parquet和CSV出圈。2024年6月，1.0“Nivis”发布，承诺存储格式和查询语义稳定。
2025年9月，1.4 LTS“Andium”带来加密、MERGE和Iceberg写入，偶数版本转LTS的节奏也定了。2026年3月，1.5“Variegata”有新CLI、VARIANT、GEOMETRY，DuckLake规范也定型了。不同信源日期有出入，具体以官方发布为准。
1.5版本有三张新牌。VARIANT把JSON这类半结构化数据拆进列存，缓解灵活schema和列存性能的矛盾。GEOMETRY让空间分析不再依赖外部扩展。CLI重写后体验更好，还支持Vortex、Lance等格式，它想做的是本地数据统一入口。
再往上走，就是DuckLake。数据层是Parquet等文件，目录层是DuckLake元数据，计算层是DuckDB引擎。它不满足于只查文件，还想管湖仓元数据，对标Iceberg和Delta。已经有人把它当成本地Athena的执行引擎。
上手也不复杂。CLI、Python、R、Java、Node、Rust、Go、ODBC都能用。Python三行就能读CSV，read_csv_auto会自动推断类型。Pandas全量读可能爆内存，DuckDB流式扫描更稳。一条SQL还能同时查CSV、Parquet、JSON，甚至挂到SQLite上。落盘就是.duckdb单文件，断电不丢。
谁该用？数据探索、日志聚合、离线报表、ETL原型、边缘嵌入式分析、本地AI训练数据过滤、替代Pandas做处理，都合适。高并发OLTP该找SQLite，超大规模分布式集群该找Spark或ClickHouse。它的价值在中间地带：Pandas撑不住，搭集群又不值。
生态上，语言绑定很多，Cloudflare、Hugging Face、MySQL、PostgreSQL、MotherDuck都有集成。扩展有httpfs、spatial、fts、VSS向量检索等。MIT协议，C++实现，GitHub星标接近4万。星标是关注度，不等于适用性。
别因为一句“太老了”就换工具，也别因为现在火就跟风。先自检三条：瓶颈是量还是并发？能不能承受集群运维？数据是落盘文件还是在线事务？DuckDB不是打爆所有引擎的锤子，它更像一把克制的刀，把本地分析里“刚好够用”变成“刚刚好快”。
热门跟贴