SQLite用了8年，我把机器人数据库换成Rust后延迟从340

我的机器人认一个人要卡0.3秒。不是算力不够，是数据库在拖后腿。

8年来SQLite是我的默认答案——配置文件、传感器日志、用户数据，甚至模型输出，全塞进去。给AI机器人做本地记忆时，这个选择看起来理所当然：嵌入SQLite，完事。

三周后，代码里攒了400行胶水逻辑，只为存取那些不是文本或数字的东西。图像嵌入、音频指纹、传感器状态向量，每个类型都要手写序列化。更头疼的是模式不兼容：昨天存的数据，今天换个模型就认不出来。

我开始怀疑SQLite是正确答案，还是只是最熟悉的那个。

AI机器人的记忆，根本不是表格

机器人记忆有个反直觉的点：AI代理记住的不是数据行，是时刻——多模态的状态快照。

一个典型场景：摄像头捕捉到人脸，生成512维嵌入向量；同时麦克风录下4KB的PCM音频片段；还有时间戳、位置、置信度。这三样东西在逻辑上是一件事，但在SQLite里要拆成：一个TEXT字段存嵌入（JSON或base64序列化）、一个BLOB存音频、两个REAL字段、一个TEXT字段。

读取时反向操作一遍。一条记录还好。一万条记录里找当前画面最相似的5张脸？你要加载用不到的blob，反序列化马上要重新编码的向量，然后在Python里逐行算余弦相似度。

我在让SQLite解决一个它不是为这个问题设计的工具。

树莓派5，8GB内存，实测数据：

存一个512维float32人脸嵌入：平均2.1毫秒

一千条记录里找Top-5相似：340毫秒（全表扫描+Python计算）

仅加载嵌入向量就吃掉180MB内存

340毫秒的识别延迟是可感知的。一个机器人认出熟人前要愣三分之一秒，体验是崩的。180MB在8GB设备上看似宽裕，但一万条记录呢？

瓶颈不是SQLite执行SQL慢，是它对向量相似搜索的抽象完全不对。

写了个Rust数据库，专门给机器人用

撞墙之后我开始做moteDB。目标很窄：用Rust写的嵌入式数据库，原生处理多模态数据，把向量搜索做成一等公民，专门跑在边缘/IoT硬件上。

和SQLite的核心差异是数据模型。没有表和行，moteDB存的是片段（fragment）——带类型的数据单元，可以是嵌入向量、blob、标量或结构化记录。一段"记忆"是带时间戳和上下文元数据的片段集合。向量搜索直接在嵌入片段上操作，跳过反序列化。

代码长这样：

use motedb::{Mote, Fragment, VecQuery};

// 存一个人脸识别时刻

.fragment(Fragment::embedding("face", &embedding))

.fragment(Fragment::blob("audio", pcm_data))

.fragment(Fragment::scalar("confidence", 0.94))

.commit();

// 向量搜索

let matches = mote.query(VecQuery::new(&current_embedding).top_k(5));

查询返回的是片段引用，不是反序列化后的对象。嵌入数据始终以float32数组形式驻留内存，相似度计算用SIMD加速，在Rust里批量完成。

同一套硬件，换moteDB后：

存嵌入向量：0.08毫秒（26倍提升）

一万条记录Top-5搜索：3.2毫秒（106倍提升）

内存占用：23MB（同数据量，8倍降低）

3毫秒对用户是无感知的。机器人终于能"瞬间"认出见过的人。

但代价是什么

不是银弹。SQLite的生态厚度moteDB没有：没有GUI管理工具，没有ORM，没有云同步方案，没有Stack Overflow上几十万条问答。

我的机器人项目不需要这些。它需要低延迟、小体积、原生向量支持，以及Rust的内存安全保证——在长时间运行的嵌入式设备上，后者比很多人想象的更重要。

另一个隐性成本：团队学习曲线。组里原本写Python的同事要接触Rust的借用检查器，头两周报错信息看得人想摔键盘。但三个月后反馈是"编译通过就跑对"的体验，在部署到100台现场设备后显得值回票价。

有个细节很有意思：迁移过程中我发现SQLite方案里30%的代码是在处理"数据到底存成了什么格式"——昨天用pickle，上周用JSON，上个月是numpy的tobytes。schema演进全靠注释和运气。moteDB的强类型片段强制你 upfront 定义结构，前期麻烦，后期省掉无数调试时间。

现在机器人跑在客户仓库里，7×24小时记录视觉-音频关联记忆。最老的那台已经攒了四万多条片段，查询延迟仍在5毫秒以内。

如果明天有人问我"嵌入式AI该用什么数据库"，我的答案变了：先问你要记住的是表格，还是时刻。