大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。
上个月看云数仓账单，差点没坐住。一个不大不小的分析任务，月费顶得上团队半个月工资。找云厂商优化配置，对方说"建议加节点"，越说越离谱。
后来我把一部分分析迁到了一个本地嵌入式数据库上。账单直接降了一大截，查询速度反而更快了。今天聊聊这玩意儿为什么能这么省，以及它到底能替代谁。
一、DuckDB是什么
DuckDB，很多人叫它"分析界的SQLite"。它不是服务器，是一个库。装进你的Python、R、应用进程里，直接跑。不用部署集群，不用先建数据仓库，pip install一下就完事。
它凭什么快？靠两样东西：列式存储和向量化执行。
列式存储，数据按列存，而不是按行。分析查询经常只取几列，按列存就能少读很多数据。
// 行式存储：一行数据连续放，取一列也要读整行
[订单1: id, 用户, 金额, 时间] [订单2: id, 用户, 金额, 时间]
// 列式存储：一列数据连续放，取一列只读一列
[所有id] [所有用户] [所有金额] [所有时间]
向量化执行，一次处理一批数据，不是一行一行来，CPU缓存用得更满。这两个特性加起来，几百MB甚至几GB的数据，在本地跑分析查询，常常只要几十毫秒。
DuckDB本身是嵌入式的，但2026年秋季即将发布的2.0版本会新增客户端/服务器模式。既能作为嵌入式数据库服务单一客户端，也能作为独立服务同时为多个客户端提供查询能力。这不改变它作为轻量级分析引擎的定位，只是让适用场景更宽了。
二、最杀的是：不用先搬数据
传统数仓最烦的一步是ETL，数据要先搬进仓库才能查。搬一次，费时间，费钱，数据还容易过时。
DuckDB不一样，它直接读文件。Parquet、CSV、JSON，甚至对象存储里的文件，一条SQL直接查。不用搬，数据在哪，就在哪查。
-- 直接查本地的Parquet文件，不用导数据
SELECT region, SUM(amount) AS total
FROM read_parquet('data/orders/*.parquet')
WHERE order_date >= '2026-01-01'
GROUP BY region
ORDER BY total DESC;
S3上的文件也一样。加个存储配置，直接查远端。查完数据不落地，账单里也没有存储费。
这就是今年圈里说的“分析能力回流”。以前分析都得上云上平台，现在本地一个进程就能跑，DuckDB直接把查询能力下沉到数据所在的地方。国产数据库也在走同一条路：KingbaseES V9通过行列混存引擎和向量化计算，在同一套架构里同时支撑交易和分析，分析查询不需要像传统数仓那样先ETL搬运。DuckDB是把能力下沉到文件，金仓是把能力融进内核，殊途同归。
三、它到底能替代谁
先泼盆冷水。DuckDB不是万能的，替代不了所有东西。我按场景划了个线。
| 场景 | DuckDB行不行 | 建议 |
|---|---|---|
| 个人探索分析、Notebook | 行 | 直接换 |
| 临时报表、嵌入式BI | 行 | 直接换 |
| 日志分析、CI数据校验 | 行 | 直接换 |
| 多用户高并发查询 | 不行 | 留给OLAP平台 |
| PB级数据仓库 | 不行 | 别硬扛 |
| 行级权限、合规管控 | 不行 | 需要平台能力 |
行业里已经有不少公开的降本案例。有团队把仪表盘从Snowflake迁到DuckDB+Parquet后，数据仓库支出降了七成以上。另一个案例里，平台从Snowflake迁过来，成本降了七成，查询还快了5到10倍。我自己的账单，也省了不止一半。
但注意，这些都是"分析型、个人型、轻量型"的场景。高并发、多租户、PB级，还得靠正经的数仓平台。
四、和云数仓，不是二选一
很多人拿DuckDB和Snowflake比，一上来就问“DuckDB是不是要干掉Snowflake”。答案其实没那么极端。
更现实的用法是混着来。分析师日常探索用DuckDB，本地查个痛快。正式报表、多用户访问，还是走云数仓。DuckDB当"第一道分析关口"，把大量临时查询拦在本地，云数仓只管正式的活。这样云账单能降，正式查询也不受影响。
ClickHouse、StarRocks那些重度OLAP，跟DuckDB也不是一个赛道。它们是分布式、多节点的，DuckDB是单机的。各干各的，各有所长。
五、我的判断
DuckDB火，不是因为它多神秘。它把"查数据"这件事，从"先建平台"变回了"直接跑"。砍掉了ETL，砍掉了集群，砍掉了巨额账单。对中小团队和独立开发者，是实打实的省钱。
但它替代不了重型平台。它更像是一块补丁，补上"太大不适合Pandas、太小不适合云数仓"的那段中间地带。而这个地带，2026年被证明比想象中宽得多。
我的建议是，别急着全量迁移。先拿一类分析任务试，跑通了再扩大。数据在哪算得快、算得省，就用哪。
避坑清单
别拿DuckDB扛高并发。它是单进程的，几百个并发用户同时查，会卡得怀疑人生。线上报表要多人访问的，老老实实走OLAP平台。我试过一次，并发一上来就跪了。
权限和合规要提前想清楚。DuckDB没有行级权限，数据脱敏、审计这些能力都弱。涉及敏感数据的，别裸着放。要么做一层应用层控制，要么干脆别用它存敏感数据。
别听几个降本案例就全量迁移。案例里的场景未必适合你。先拿一类分析试，算清楚存储、查询、运维这三笔账，再决定迁不迁。盲目迁移，省了云费，可能费了人力。
再说个最新的动态。就在最近，AWS宣布收购了DuckDB的母公司DuckLabs，计划保持项目开源，同时提供DuckLake等生态项目。大厂入局，说明嵌入式分析这条路走通了。对DuckDB用户来说是好事，生态会更稳，也不用担心项目黄了。
你们数仓账单多少？云数仓会被DuckDB干掉吗？评论区聊聊。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
