做本地优先的控制面时，很多人会纠结”要不要直接上 Postgres”。我的答案是：在没有明确的服务器端需求之前，SQLite 往往更合适。它不是一个”玩具数据库”，而是一个被严重低估、完全能扛住单机控制面的存储。

我在做 Agent 平台（agent-hub）时，用的就是本地 SQLite 存工作区等状态。这篇讲它为什么够用，以及边界在哪。

为什么 SQLite 够用

控制面的数据量通常是小、结构化、单机可容纳的——工作区列表、配置、一些状态。它不像业务系统那样有海量写入和高并发。

SQLite 在这类场景有它的优势：

  • 零运维：就一个文件，备份、迁移、拷走都简单；不用装服务、不用管连接池。
  • 和”本地优先”天然契合：数据就在本地，进程能直接读，不需要跨网络。
  • 事务和唯一约束都齐全：做幂等去重（用唯一索引）、保证一致性，完全够。
  • 单文件、可读：出问题时可以直接用工具打开看，调试友好。

对一个”一个人跑的本地控制面”，这些好处远比”能撑几万并发”重要。

边界在哪——这才是重点

但 SQLite 不是没有边界。关键要清楚它适合什么、不适合什么，别用错地方：

  1. 并发写是瓶颈：SQLite 同一时刻一般只有一个连接能写（写锁）。单进程、低频写没问题；一旦多进程、并发写多了，就会锁等待、报 database is locked。
  2. 不适合多机、远程：它是文件级引擎，天然是单机、本地。要多机共享、跨机器访问，就该换服务器型数据库。
  3. 不适合超大/高频写：海量事件、高频写入，SQLite 会吃力；而且那个单文件会越滚越大，需要压缩/归档。
  4. 多租户、细粒度权限：SQLite 做不了真正的行级租户隔离和安全边界，这本来就是服务器 + 鉴权该干的。

一句话：SQLite 适合”单机、本地、低频写、数据量可控”的控制面；一旦要”多机、多写、多租户、海量”，就该换。

判断的朴素标准

我不靠”哪个听起来高大上”来选，而是问自己：

  • 这个存储是单机用吗？是 → SQLite 够。
  • 会有多个进程同时写吗？会 → 要小心，可能得上锁或换库。
  • 数据会非常大或写非常频繁吗？是 → 换。
  • 需要多机共享 / 远程访问 / 租户隔离吗？是 → 换。

如果答案都是”否”，那 SQLite 就是正确选择，别为了显得”专业”去背一个 Postgres 的运维负担。

最后几条

  • 本地控制面用 SQLite，零运维 + 本地优先 + 事务齐全，够用且顺手。
  • 边界：单机、低频写没问题；多机/多写/多租户/海量就换。
  • 别为了”听起来专业”而上重数据库，那是在为想象的需求买单。
  • 选型靠”适不适合”，不靠”高不高级”。

“够用”这两个字，很多时候正是正确的选择。