做个小Agent，别第一天就把数据库搭成机房

一个本地 Agent 通常要存四类东西：聊天记录、任务跑到哪一步、用户设置，以及方便以后找资料的向量索引。最近一组公开测试拿 SQLite 和本机 PostgreSQL 做了对比，在 1000 条模拟记忆的条件下，SQLite 冷启动约 7.9 毫秒，PostgreSQL 约 53 毫秒；写入吞吐约为每秒 1700 次对 289 次。这个结果能说明小数据、单机直连时 SQLite 很轻快，但不能证明它在所有场景都快六倍。测试机器、驱动、表结构和并发方式一换，数字就会变。真正靠谱的事实是：SQLite 直接嵌在程序里，一个文件就能用；PostgreSQL 是独立服务，能力更多，搭建和维护也更多。

一个人用，先把东西存明白

假如你做的是个人资料整理 Agent：记住聊过什么、保存几个任务状态、从几万条笔记里找相近内容。SQLite 不用单独启动数据库服务，复制一个文件就能备份，发 Demo 时也省心。需要按意思找笔记，还能接 sqlite-vec 这类向量扩展。它目前仍是 1.0 之前的版本，可能有不兼容改动，但拿来做原型和本地工具，确实够轻。

这时候一上来就装 PostgreSQL、配连接池、跑迁移、守着数据库进程，容易把半天花在机房装修上，Agent 本身还没干上一件正经事。别看配置多就觉得专业。小摊刚开张，先把收钱、记账、找货跑顺，比先盖个仓储中心强。

真正的分界线，不是用户到了某个神奇数字

原文给出“多少人以下用 SQLite”的判断，很好记，但现实没那么整齐。一个人让 Agent 连续导入十万份文件，写入压力可能比五十个人偶尔点一下还大；一千个人只读公开知识库，也未必马上把 SQLite 压垮。该看的不是注册人数，而是有没有很多人同时写、数据是不是跨机器、能不能接受短暂排队。

SQLite 官方说得很清楚：它可以同时服务很多读取，但同一时刻只允许一个写入者。打开 WAL 模式后，读和写可以并行，多个写入仍得排队。PostgreSQL 用多版本并发控制，让多人读写时少互相堵路。像团队里的 Agent 同时改工单、写聊天、更新任务状态，或者服务跑在多台机器上，PostgreSQL 才是真正开始显出价值。

有“记忆”也不等于必须上重型数据库

向量索引就是把一段文字变成一串数字，方便按意思找相近内容。SQLite 有 sqlite-vec，PostgreSQL 有更成熟的 pgvector，支持精确搜索，也支持 HNSW、IVFFlat 这类用一点准确率换速度的索引。可别一听“长期记忆”就条件反射上大数据库。只有资料真的多、过滤条件复杂、多人同时更新，或者已经需要严格的数据隔离时，那些高级能力才值回维护成本。

反过来也别把 SQLite 吹成万能单文件。数据跨多台机器、写入特别频繁、需要多租户权限和成熟运维时，硬扛只会把简单省下来的时间，后来全补在排队、同步和排错上。工具轻不轻不重要，得看它是不是正好压住眼前的活儿。

我的看法：先选够用的，再等瓶颈自己露头

数据库选型最怕两种毛病：一种是“大家都用这个，我也得上”；另一种是拿一次跑分当圣旨。前者容易过度建设，后者容易忽略真实业务。更实在的顺序是，先弄清存什么，再看谁同时写，最后才看向量规模和权限要求。

本地工具、个人助手、刚起步的 Demo，用 SQLite 往往更麻利；多人持续写入、跨机器服务、严格隔离的数据，PostgreSQL 更稳。等监控真的告诉你写入在排队、查询开始慢、单机扛不住，再迁移也不迟。第一天最值钱的不是把架构画得像大厂，而是让 Agent 真正完成一次任务。库房以后可以扩，买卖还没开张就先修八个卸货口，那多少有点整岔劈了。