Show HN: Wolbarg – 基于 SQLite 的本地优先 AI Agent 共享内存

当人们构建 AI 应用时，数据库的选择似乎很明确：PostgreSQL，或许用 Redis 做缓存，或许用 pgvector 做语义搜索。SQLite 几乎从不被考虑。

这让我很惊讶。在构建并评测一个面向 AI Agent 的本地优先语义记忆层时，我最终总是得到一个单文件、无服务器、无连接池、无需 Docker 容器——只是为了记住 Agent 五分钟前说过的话。

这篇文章就是关于这个决策，以及为什么 SQLite 通常更适合本地多 Agent 工作流。

Postgres 之所以成为默认选择，是因为它为人熟知——能处理并发用户，拥有庞大的扩展生态，能为每个边缘情况提供答案。所以当你开始存储 AI 记忆时，你的大脑会自然想到那套惯用技术栈：启动 Postgres，加装 pgvector，配好连接字符串，并祈祷你的本地环境有朝一日能和线上环境一致。

这条路没有错。只是对大多数本地 AI 工作来说，它过于沉重了。

本地 Agent 通常运行在一台机器、一个进程内，或许有少数几个 Agent 共享上下文。这里的“数据库”只是意味着持久的存储，并具备按语义搜索的能力。为此你不需要一个网络守护进程——你需要的是启动快速、不碍事、且不会在你笔记本休眠时挂掉的东西。

剥去营销话术，需求列表很短：低延迟，简单（无需折腾迁移、用户或角色），本地执行（能离线工作，没有云账单），可靠性（事务，不会写出半截的记忆），以及持久性（一个你可以复制、备份或删除的文件）。

复制、水平扩展、多租户连接池——这些解决的是你尚不存在的问题。

SQLite 是一个库，而不是服务器。你的应用打开一个文件，引擎在你的进程内部运行，用完后你关闭文件。这解释了它在这里为何适用。

单文件。 删除它就能重置状态。压缩它就能分享演示。用任何 SQLite 浏览器都能查看 Agent 存储的内容。

无服务器。 无需 docker compose up，没有因系统更新而和你较劲的服务，不会在凌晨一点报“连接被拒绝”。

无仪式感的 ACID。 一次写入如果同时触及记忆行、其嵌入向量和一个关键词索引，要么完全落地，要么完全回滚——除非你自己设计，否则不会出现“文本已保存，嵌入向量丢失”的情况。对于语义记忆来说，文本和嵌入向量保持同步不是可选项。

快速启动，低开销。 无需另一个进程预热缓存。打开一个本地存储只需要毫秒级时间，因为你的应用旁边没有第二个运行时在启动。

那种旧印象已经过时了。SQLite 是经过调优的 C 语言实现，历经数十年在浏览器、手机和嵌入式系统中的实战检验。对于能放在单机上的工作负载——正是本地 Agent 的场景——它通常比网络数据库更快，因为网络延迟完全消失了。一个本地 SELECT 直接从磁盘或操作系统页面缓存读取；而本地主机上的 Postgres 查询仍然要通过套接字和独立的进程。

在我自己的基准测试中（模拟嵌入向量，1,000 条记忆），SQLite 在笔记本多 Agent 工作流中表现良好：

冷启动（毫秒）——越低越好 搜索 / 召回（1,000 条记忆下，毫秒）——越低越好

SQLite vs 本机 PostgreSQL。同一台机器，相同的 SDK 路径——差距主要来自进程和套接字开销，而不是原始查询的巧妙程度。

对于这种规模的语义记忆，瓶颈几乎从来不是 SQLite——而是嵌入调用、模型，或者 Agent 循环中等待工具的时间。

Agent 需要按含义回忆，而不仅仅是关键词。“用户偏好深色模式且讨厌弹窗”应该在你随后问“我们知道哪些 UI 偏好？”时被检索出来——单纯的关键词搜索可能会错过它。

每条记忆都变成一个嵌入向量——一组数字，相似的语义最终在空间中接近。人们认为这需要专门的向量数据库。在本地，并不需要。SQLite 可以直接存储嵌入向量并检索它们；像 sqlite-vec 这样的扩展提供了合适的向量索引，而在无法使用时你可以回退到使用 blob 和进程内余弦相似度。再配合关键词索引（FTS5），你就得到了混合搜索——语义加上精准的标记，比如错误代码和 ID。所有这些都不需要服务器。

那个令人紧张的问题：如果研究者、撰稿人和评论者 Agent 都共享记忆，你难道不需要一个能妥善处理并发访问的东西吗？

在本地，通常不需要。你不是在网络上跑着成百上千个独立的客户端——一个进程协调着少数几个读多写少的 Agent。SQLite 在 WAL 模式下能很好地处理这一点，读者可以在写操作进行时继续读取，而不是所有人排在一个锁后面。写操作仍需小心：SQLite 一次只允许一个写入者，因此一个本地 SDK 会用互斥锁序列化写入，并将每次插入包裹在事务中。

这是一个限制吗？是的。但当写入已经被 LLM 延迟所限定时，这还是个问题吗？很少——你是在推理步骤之间存储少量记忆，而不是从十个微服务每秒进行 50,000 次插入。

当你遇到服务器规模的问题时，再考虑 Postgres：云 SaaS，有许多来自不同机器的并发写入用户；需要跨多个应用服务器或区域的分布式系统；复制和故障转移需求；对亿万行数据进行分析；或者团队已经在 Postgres 运维上标准化了。

重点不是“永远不用 PostgreSQL”。而是：不要仅仅因为感觉更专业，就为本地 AI Agent 从它开始。复杂性是一种成本——当问题确实需要时才付出它。

当应用运行在单机上，Agent 在一个进程或一个小的本地集合内共享内存，你想要零运维的配置，并且你的数据规模更像是“项目知识”而非“互联网级语料库”时，使用 SQLite。当多个远程客户端需要实时共享内存，你已经在生产环境里使用 Postgres，或者你需要 SQLite 单写入者模型无法承受的并发写入量时，使用 Postgres。

大多数本地多 Agent 工作流都属于第一类。人们只是没注意到，因为每个教程都以 Postgres 开始。

对于本地 AI Agent 记忆来说，SQLite 不是一种妥协——对许多构建者而言，它是正确的初始架构。持久的存储、事务、快速的本地读取、基于嵌入向量的语义搜索、跨 Agent 的共享内存，所有这些都在一个你真正看得懂的文件里。

Postgres 非常优秀。它只是解决了一个与大多数本地 Agent 不同的问题。从简单开始，在本地存储记忆，当真正的并发或分布需求出现时再加入服务器数据库——而不是在那之前。你可能会发现，一直以来你都在过度设计。

AM

作者：Atharv Munde

正在构建 Wolbarg——面向 AI Agent 的本地优先语义记忆。

When people build an AI application, the database choice looks obvious: PostgreSQL, maybe Redis for caching, maybe pgvector for semantic search. SQLite almost never makes the list.

That surprised me. While building and benchmarking a local-first semantic memory layer for AI agents, I kept ending up with a single file, no server, no connection pool, no Docker container just to remember what an agent said five minutes ago.

This post is about that decision, and why SQLite is often the better fit for local multi-agent workflows.

Postgres wins by default because it's familiar — concurrent users handled, huge extension ecosystem, an answer for every edge case. So when you start storing AI memory, your brain reaches for the usual stack: spin up Postgres, add pgvector, wire up a connection string, hope your local setup matches production someday.

That path isn't wrong. It's just heavier than most local AI work needs.

Local agents usually run on one machine, one process, maybe a handful of agents sharing context. "Database" here just means durable storage with a way to search by meaning. You don't need a network daemon for that — you need something that starts fast, stays out of the way, and doesn't die when your laptop sleeps.

Strip away the marketing and the list is short: low latency, simplicity (no migrations, users, or roles to wrestle with), local execution (offline works, no cloud bill), reliability (transactions, not half-written memories), and persistence (a file you can copy, back up, or delete).

Replication, horizontal scaling, multi-tenant connection pooling — those solve problems you don't have yet.

SQLite is a library, not a server. Your app opens a file, the engine runs inside your process, you close the file when you're done. That explains most of why it works here.

One file. Reset state by deleting it. Share a demo by zipping it. Inspect what an agent stored with any SQLite browser.

No server. No docker compose up, no service fighting you on an OS update, no "connection refused" at 1 a.m.

ACID without ceremony. A write that touches a memory row, its embedding, and a keyword index either fully lands or fully rolls back — you don't get "text saved, embedding missing" unless you design for that yourself. For semantic memory, text and embedding staying in sync isn't optional.

Fast startup, low overhead. No separate process warming caches. Opening a local store takes milliseconds, because there's no second runtime spinning up next to your app.

That reputation is outdated. SQLite is tuned C, battle-tested for decades across browsers, phones, and embedded systems. For workloads that fit on one machine — exactly what local agents are — it's often faster than a networked database, because network latency just disappears. A local SELECT reads from disk or the OS page cache; a Postgres query on localhost still goes through sockets and a separate process.

In my own benchmarks (mock embeddings, 1,000 memories), SQLite held up fine for a laptop multi-agent workflow:

Cold startup (ms) — lower is better Search / recall at 1,000 memories (ms) — lower is better

SQLite vs PostgreSQL on localhost. Same machine, same SDK path — the gap is mostly process + socket overhead, not raw query cleverness.

For semantic memory at this scale, the bottleneck is almost never SQLite — it's the embedding call, the model, or the agent loop waiting on tools.

Agents need to recall by meaning, not just keywords. "The user prefers dark mode and hates popups" should surface when you later ask "what UI preferences do we know?" — a plain keyword search might miss it.

Every memory becomes an embedding — a list of numbers where similar meanings end up close together. People assume that needs a specialized vector database. Locally, it doesn't. SQLite can store embeddings and search them directly; extensions like sqlite-vec add proper vector indexes, and where that's unavailable you fall back to blobs and in-process cosine similarity. Pair that with a keyword index (FTS5) and you get hybrid search — meaning plus exact tokens like error codes and IDs. None of it needs a server.

The nervous question: if a researcher, writer, and critic agent all share memory, don't you need something that handles concurrent access properly?

Locally, usually not. You're not running hundreds of independent clients over a network — one process is coordinating a few agents that read often and write rarely. SQLite handles this well in WAL mode, where readers keep reading while a write happens instead of everyone queuing behind one lock. Writes still need care: SQLite allows one writer at a time, so a local SDK serializes writes with a mutex and wraps each insert in a transaction.

Is that a limitation? Yes. Is it a problem when writes are already bounded by LLM latency? Rarely — you're storing a handful of memories between reasoning steps, not doing 50,000 inserts a second from ten microservices.

Reach for Postgres when you have server-shaped problems: cloud SaaS with many concurrent users writing from different machines, distributed systems spanning multiple app servers or regions, replication and failover requirements, analytics over hundreds of millions of rows, or a team that's already standardized on Postgres operations.

The point isn't "never use PostgreSQL." It's: don't start there for a local AI agent just because it feels more professional. Complexity is a cost — pay it when the problem demands it.

| SQLite| PostgreSQL
---|---|---
Setup| Open a file| Install, configure, connect
Deployment| Ships with the app| Separate service to run
Concurrency| One writer, many readers (WAL)| Many concurrent writers
Operations| None| Backups, replicas, access control
Best use case| Single machine, local agents| Multi-client, networked, production scale
Local-first experience| Native| Requires extra infrastructure

Use SQLite when the app runs on one machine, agents share memory inside one process or a small local set, you want zero-ops setup, and your dataset looks more like "project knowledge" than "internet-scale corpus." Use Postgres when multiple remote clients need live shared memory, you already operate Postgres in production, or you need concurrent writers at a scale SQLite's single-writer model can't absorb.

Most local multi-agent workflows fall in the first bucket. People just don't notice, because every tutorial starts with Postgres.

SQLite isn't a compromise for local AI agent memory — for a lot of builders, it's the correct first architecture. Durable storage, transactions, fast local reads, semantic search with embeddings, shared memory across agents, all in a file you actually understand.

Postgres is excellent. It just solves a different problem than the one most local agents have. Start simple, store memory locally, and add a server database when real concurrency or distribution shows up — not before. You might find you were overengineering this the whole time.

AM

Written by

Atharv Munde

Building Wolbarg — local-first semantic memory for AI agents.