一个 AI Agent 做一次决定，背后要查好几套系统。用户资料在 Postgres，会话状态在 Redis，历史对话的向量在 Pinecone，跑完的指标在 ClickHouse。四套库，四份连接，四套同步逻辑——Agent 越能干，这套拼接越像埋在地板下的水管，漏了才知道。

ParticleDB 想把这四根管子并成一根。它把自己描述成“给 AI Agent 的数据库”，官网 首页只有一句话：关系型事实、向量记忆和实时运营数据，放进一个引擎。

一个 Agent 的一次决策，要查四种库

拿客服 Agent 举例。它要先读工单表，确认这个用户买了什么；再查会话状态，知道上一步问到哪；然后做一次向量检索，找出相似的退款政策；最后跑一条聚合，看看这类问题最近是不是在变多。

这四步在传统架构里要跨四个系统。每一步都有网络往返，每一步都可能读到旧数据。真正贵的不是查询，是把四份数据拼成一个能用的上下文。

ParticleDB 的卖点就落在这里：同一个引擎里，SQL、KV、向量和 OLAP 都能跑，数据不用搬来搬去。

一个引擎，五种负载

它把能力拆成五块：

  • 关系型 SQL：表、join、ACID 事务，兼容 PostgreSQL 的连接方式；
  • 键值：兼容 Redis 的命令，用来做队列、锁、计数器和限流；
  • 向量检索：VECTOR 类型加距离排序，和普通 SQL 条件写在同一条查询里；
  • 实时分析：列式执行，直接查运营数据，不需要 ETL 和第二份拷贝；
  • Particles：用 Python 写的标量函数，注册后能在 SQL 里直接调用。

安装是一条 curl 脚本，启动是一个 particledb start。服务端默认监听 7173，自带一个叫 Studio 的 Web 控制台，端口 7174，能看 SQL 事务、KV、向量、分析和系统资源。它不是一个套在别的数据库外面的壳，官方说法是从存储、查询到事务全部自己实现，用的是 Rust。

客户端也给得比较全：Python、TypeScript、Java、Go、Rust 的 SDK，加一个 JDBC 驱动。现有项目不用换技术栈，拿熟悉的驱动连上去就行。

同一份数据，换四种接口读

最能说明设计意图的是一个很小的例子。先用 Redis 客户端写一个状态：

redis-cli SET agent:status running

再用 SQL 读同一个键：

SELECT KV_GET('agent:status') AS status;

返回 running。同一份数据，多个接口，一个数据库。对 Agent 来说，它可以在一段逻辑里用 KV 管状态、用 SQL 查事实、用向量找记忆，不用为每种操作维护一套连接池和一致性策略。

向量查询也放在 SQL 里，不另开一套 DSL：

SELECT id, note FROM memories
ORDER BY embedding <-> $1 LIMIT 2;

距离运算符 <-> 和普通 WHERE 条件可以混着写。先按业务字段过滤，再做相似度排序，这一步在拼四套库的架构里通常最麻烦。

Particles：把 Python 搬到数据旁边

Particle 是这堆能力里最不像传统数据库的部分。写一个普通 Python 函数，加上 @scalar，启动服务时把文件传进去，它就能在 SQL 里被调用：

SELECT agent_priority(0.5, 0.75) AS priority;

官方的例子是给 Agent 的候选动作打分：impact * confidence。传统做法是把候选行全部拉到应用层，算完再写回去；Particle 的做法是在数据旁边算，只把结果带出来。省掉的不只是一次网络往返，还有“算到一半应用挂了”的那类一致性问题。

目前只支持 Python，官方说其他运行时还在计划里。这个限制很实在：想用 Go 或 Rust 写复杂逻辑，现在还得放在应用层。

最该看的一段：Jepsen 的 96 个问题

新数据库最怕两件事：只放性能图，不讲一致性。ParticleDB 这次把另一面也放出来了。

他们请 Kyle Kingsbury（Jepsen）做了独立测试，覆盖 1.1.4 到 1.1.18.11.rc-22 这些版本，一共记录了 96 个问题，范围包括 SQL 正确性、事务隔离、并发异常和数据丢失。更刺眼的是，很多问题出现在没有注入故障的单机部署上。

官方的说法是，到 1.1.19 为止，报告里的问题都已处理。这个态度比“我们很快”有用，但也说明一件事：这套引擎的成熟度还在早期。单机都能测出数据丢失，生产环境里遇到磁盘抖动、网络分区、并发写入，风险只会更高。

现在该不该用

如果你的项目正好被“四套库 + 同步任务”折磨，ParticleDB 值得开个沙箱试。它的接口设计确实省事，SQL、KV、向量写在同一个查询里的体验，和拼四个客户端完全不一样。

但别急着把核心账务搬过去。它的基准测试页面目前没有可比的性能结论，官方明确说，没有可复现的结果包就不发布对比数字；ClickBench、TPC-C、OLAP 和 KV 对比都还在跑。GitHub 上的存在感也还很弱，server 仓库只有 4 个 star。

比较稳妥的用法是：内部工具、原型、Agent 的记忆和状态层，先跑起来看看。真要做生产数据库，先拿自己的数据量和查询模式压一遍，再读一遍 Jepsen 报告原文，别只看官网首页那五张能力卡片。

数据库这个行业，功能可以一夜补齐，信任只能一轮一轮测试攒出来。ParticleDB 把 96 个问题摊开讲，这一步比多写五个 SDK 更像在做长期生意。