oceanbase/seekdb

如果你在做 Agent 记忆或检索，受够了把事务库、向量库、搜索引擎拼在一起再写客户端胶水代码，seekdb 值得一看。但它不是跑个 demo 那么轻的决定，先用嵌入式 SDK 路径建立判断成本最低。

解决什么问题

做 Agent 记忆的开发者通常想完成这样一件事：写入一条记录、拿到 embedding，一秒后既按语义相似度、又按关键词和元数据过滤把它找回来。现在这套流程散落在多个系统里——事务数据库存 Agent 状态，向量库存 embedding，搜索引擎做全文。要保持一致就得写后台同步任务，最后还得在应用层合并排序。seekdb 改的是「合并结果」这一步：向量距离、MATCH ... AGAINST 全文匹配和普通标量条件被推进同一个 SQL 执行计划，应用发一条查询就能拿到一个有序结果集 项目说明。

有什么不同

最值得注意的设计是 README 称为 Change Stream 的异步索引管线：提交事务后不必等索引构建完成就返回，redo log 被异步消费，用来更新带增量层和快照层的两级 HNSW 索引，新写入的向量很快可查。对持续写入、稍后就读的 Agent 负载来说，这个解耦正是要验证的部分。代价是指数异步跟随日志，高负载下实际能拿到多新的索引是个真问题，默认 demo 回答不了。

第二个特色是 copy-on-write 沙箱：FORK DATABASE 秒级快照且不复制数据，Agent 可以随意写入甚至弄坏表，之后用 MERGE TABLE 按 FAIL/THEIRS/OURS 策略把工作合回主线，或 DROP DATABASE 丢弃。这是内核层而非应用层的保存/恢复。fork 只是方便实验，不构成备份保证，也不说明快照能保留多久。兼容 MySQL 且支持 ACID，意味着现有 SQL 工具和驱动大多能直接用 项目说明。README 还展示了宣称是 Milvus 10.7 倍、Elasticsearch 3.2 倍 QPS 的跑分图，并提供了复现仓库 跑分工具；在拿自己的数据跑过之前，请把它当作厂商说法。

谁值得试

适合：正在做 Agent 状态、RAG 或混合检索、团队本身认 SQL 和 MySQL 语义、希望用一个引擎替掉三套系统的团队。Python、Node.js、Go 的嵌入式路径 嵌入式 SDK 选项 让你不必先部署服务就能本地评估。不适合：已经在用调好的向量库加搜索栈且没有一致性痛苦的团队，或者需要大量成熟运维工具和现成社区答案的人。如果你的检索是纯向量、从不需要文本或过滤，all-in-one 的卖点对你价值不大。

使用条件与边界

安装本身不难：Python 路径要求 Python 3.11 以上，装 pylibseekdb 和 MySQL 驱动即可 Python SDK 包。难的是长期维护：你接手的是一个出自 OceanBase 血脉的 C++ 数据库引擎，升级、异步索引管线、COW fork 与 merge 的语义，团队都得真正理解，而不是装上就算。README 列了嵌入式、单机服务、分布式集群三种部署形态，运维负担差别极大。

跑分数据来自项目自己的工具和硬件，在你写入密集的 Agent 循环里表现如何需要自己测。现有文档摘录没有说清索引新鲜度的延迟目标，也没说清快照的长期行为，这两点是在生产依赖之前要弄明白的未知数。

HotRepo 点评

HotRepo 的日期记录很薄：仓库创建于 2025-10-21，2026-10-28 当天登上日榜一次，星数 3,197、当日 +6 项目页。只有一个快照，无法判断热度是持续还是消退。下一步该看的是跑分复现仓库和你自己的「写入后立即检索」延迟测试，而不是星数。