AI Infra：DuckDB v2.0 Preview 发布
“the year of DuckDB as a server”，DuckDB 正在从“嵌入应用里的分析引擎”，扩展成“可以嵌入、可以独立运行、可以连接远端数据源、可以直接查询 Lakehouse 的轻量数据 runtime”。
一、DuckDB 2.0 最大变化：Server 化
核心是两个东西：
Quack
DuckDB 原生远程协议。
任何 DuckDB Process 都可以：
DuckDB
↓
quack_serve()
↓
Network成为 Server。
CONNECT
另外一个 DuckDB 可以：
DuckDB Client
CONNECT
│
▼
DuckDB Server甚至可以直接：
DuckDB
│
├── CONNECT PostgreSQL
├── CONNECT MySQL
└── CONNECT DuckDB而且 Query 可以 Pushdown 到远端数据库执行。这会产生一个很有意思的产品形态：
Application
│
▼
┌──────────┐
│ DuckDB │
└──────────┘
/ | \
/ | \
▼ ▼ ▼
DuckDB PG MySQL
Server
+
S3 / Lake
Parquet / Iceberg此时 DuckDB 已经开始具备：Local Engine + Remote Query + Federation + Lake Query 四种能力。这让 DuckDB 从 Embedded Database 变成了 Data Runtime
这是我认为这次升级最值得关注的产品变化。
Application / Agent
│
▼
┌────────────┐
│ DuckDB │
│ Data Runtime│
└────────────┘
│ │ │
┌─────────┘ │ └─────────┐
▼ ▼ ▼
Local DB Remote DB Lakehouse
PG/MySQL S3/Parquet应用不需要关心：
数据究竟在本地 DuckDB、远端 DuckDB、PostgreSQL、MySQL，还是 S3 Parquet。DuckDB 开始承担一个新的角色：
把 Application 和底层异构数据系统隔开。已经具有比较明显的 Runtime 产品特征。
二、VARIANT 推进到完整的数据处理链路
DuckDB 1.5 已经引入 VARIANT，2.0 将它推进到完整的数据处理链路。
官方把它描述成：
JSON on steroids.
原因在于 JSON 通常是文本。
例如：
{
"user": {
"id": 42
}
}传统 JSON 数据库处理路径：
JSON Text
↓
Parse
↓
Extract
↓
QueryDuckDB VARIANT 会识别不同记录之间的共同结构，然后进行 shredding：
Semi-structured Data
↓
┌───────────────────┐
│ VARIANT │
│ │
│ user.id → column │
│ user.tag → column │
│ ... │
└───────────────────┘
↓
Columnar Execution用户依然可以：
Schema-less 写入。
数据库内部则获得：
Schema-aware Execution。
v2.0 进一步支持 shredded execution、scan extraction pushdown、Parquet VARIANT 读写等。
这对于 AI / Agent 场景尤其重要。
因为 Agent 产生的数据天然高度半结构化：
Agent Event
Tool Call
Trace
Message
Observation
State
Context
JSON Log这些数据 Schema 经常变化。
VARIANT 很适合成为：
Agent Event / Context
↓
VARIANT
↓
Columnar Analytics因此 DuckDB 可能逐渐成为 Agent 本地数据处理层 的候选组件。
三、DuckDB 开始具备“业务数据库”能力
一个容易被忽略的更新是：Triggers。
DuckDB 2.0 支持：
BEFORE
AFTER
FOR EACH ROW
FOR EACH STATEMENT
OLD TABLE
NEW TABLE例如：
UPDATE order
│
▼
Trigger
│
▼
Audit Table这意味着 DuckDB 可以承担：
审计、CDC-like logic、状态变化处理、事件驱动逻辑。
官方也明确指出 Triggers 与 long-running DuckDB services 很自然地结合。
再加上 DuckDB 原本已经具备：
MVCC
Transaction Isolation
Multi-connectionServer Mode 出现以后，这些能力开始获得真正的产品价值。
DuckDB 官方甚至表示，在部分事务 workload 上已经可以与 PostgreSQL 竞争。
于是产品边界开始出现变化：
以前
DuckDB
≈ Analytical Engine
现在
DuckDB
≈ Analytical Engine
+ Transaction
+ Trigger
+ Server
+ Federation它正在靠近一个更完整的数据库 Runtime。
四、Lakehouse 性能进一步加强
DuckDB 原本最大的杀手级产品能力之一就是：
直接查询 S3 上的 Parquet。
不需要：
S3
↓
ETL
↓
Database
↓
Query直接：
S3 / Parquet
│
▼
DuckDB
│
▼
Queryv2.0 增加了 Asynchronous I/O。
以前：
Query Thread
│
▼
Network I/O
│
wait现在 I/O 和 Query Processing 可以独立扩展：
Query Engine
/ | \
/ | \
Async IO Async IO Async IO
│ │ │
▼ ▼ ▼
S3 S3 S3尤其针对：
S3、Parquet、DuckLake、Iceberg。
网络存储读取会明显受益。
这进一步强化了 DuckDB 的一个长期产品方向：
Compute 可以极轻，Data 可以留在 Object Storage。
五、SQL 正在变成数据计算 DSL
这部分对于 Agent 很值得关注。DuckDB 2.0 加入：
NEAREST JOIN
直接：
APPROX NEAREST 2
BY SIMILARITY ...也就是把：
Vector Similarity Search
变成标准 SQL Join。
还有：
Recursive CTE USING KEY
可以执行 iterative algorithm。
官方给出的 benchmark 非常夸张：
| 版本 | 100 万 edge 图递归查询 |
|---|---|
| DuckDB 1.5.4 | 4.90s |
| DuckDB 2.0 Preview | 0.12s |
约 40×。当然这是官方选择的 microbenchmark，不能直接外推到所有 workload。
再加上：
JSON
VARIANT
Vector
Recursive CTE
DML in CTE
Nested SchemaDuckDB 的 SQL 已经逐渐可以表达：
Relational
+
Semi-structured
+
Vector
+
Graph-like recursion
+
ETL pipeline对于 AI 应用，这一点可能比单纯 benchmark 更重要。
六、从产品地图看 DuckDB 2.0
如果把数据基础设施简化成几个产品：
Data Infrastructure
OLTP OLAP Lake
│ │ │
▼ ▼ ▼
PostgreSQL ClickHouse Iceberg
│ │ │
└──────────┐ │ ┌──────────┘
│ │ │
▼ ▼ ▼
DuckDB 2.0
┌──────────────────┐
│ Local Execution │
│ Remote Execution │
│ Federation │
│ Lake Query │
│ Vector │
│ Semi-structured │
└──────────────────┘
│
▼
Application / AgentDuckDB 很有意思的一点是：
它没有强迫用户把 Data 搬进 DuckDB。和传统数据库形成明显区别。
七、对 AI / Agent Infra 来说，这次变化尤其值得关注
Agent 数据天然包括：
Business Data
Agent State
Tool Result
JSON Event
Vector
Context
Logs
HistoryDuckDB 2.0 已经开始同时处理：
Agent
│
▼
┌───────────────┐
│ DuckDB │
│ │
│ SQL │
│ VARIANT │
│ Vector │
│ Transaction │
│ Trigger │
│ Federation │
└───────────────┘
│ │ │
▼ ▼ ▼
PG S3 Lake所以从创业和投资视角看，我认为 DuckDB 2.0 最值得关注的信号并非某一个数据库功能。
它在验证一个越来越重要的产品范式：
数据库正在从“Data Destination”变成“Application Runtime Component”
以前：
Application
│
▼
Database Server
│
▼
Data现在：
Application / Agent
│
┌───────┴───────┐
│ Data Runtime │
│ DuckDB │
└───────┬───────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
Local SaaS DB Object Store
PG S3/Lake计算越来越靠近 Application，数据可以留在原来的位置。DuckDB 当前主要解决的是 Query / Analytics Runtime。Agent 真正需要的 State Runtime 还涉及长期状态、多 Agent 并发、Context 生命周期、Fork / Merge / Rollback、语义对象以及 Agent execution consistency 等问题。
标签：无