puppyone vs Postgres / Supabase：关系型 schema vs 给 Agent 用的文件工作空间
TL;DR
- Postgres / Supabase 是关系型数据库。 表、列、类型、事务、SQL —— 为有规则形状的结构化数据设计。
- puppyone 是给 AI Agent 用的、文件形态、带版本的上下文层。 文件、路径、commit、per-agent 权限、MCP / Bash / REST —— 为 LLM 真正想读的非结构化上下文设计。
- 它们不是一个品类。问"Postgres vs puppyone"就像问"MySQL vs Dropbox" —— 答案几乎永远是"两个一起用，做不同的事"。
- 生产里的常见模式：Postgres / Supabase 存结构化的应用数据；puppyone 存非结构化的上下文（规格、文档、Agent 输出、Postgres 查询的物化切片）让 Agent 真正去读写；Agent 需要新数字时，通过 puppyone 暴露的 SQL 连接器去打 Postgres。
老实话
Postgres 是人类做过最好的关系型数据库。Supabase 把它的开发体验做得非常好。我们自己用，客户用，我们认识的所有正经团队都在用。
我们不替代它们。我们也不想替代。
我们替代的是它们上面那一层 —— Agent 读写非结构化上下文的地方，那些塞不进一行的东西。规格。长篇研究。生成的报告。多步计划。对话快照。Slack 线程转 markdown。Postgres 一段查询的物化切片，作为文件让 Agent 用 cat 读，而不是跑 30 个 select。
把这种上下文塞进 Postgres 是能跑的，直到不能。下面解释什么时候开始不能。
并排对比
| 维度 | Postgres / Supabase | puppyone |
|---|---|---|
| 数据形状 | 类型化列里的结构化行 | 非结构化文件（markdown / JSON / CSV / 任何东西） |
| 查询模型 | SQL | cat / ls / grep / MCP read_file |
| Schema | 必须、强制、要 migration | 文件系统层级，无 schema migration |
| 主要用户 | 应用代码、分析师 | AI Agent，以及配置它们的人 |
| 权限 | RLS / 角色 / per-table grant | per-agent Access Point，按路径 scope 读/写 |
| 版本 | 应用层：append-only 表、history 列、CDC、或者没有 | 内置：每一次写都是 commit，带 author / diff / 回滚 |
| 审计 | trigger / pgaudit / 外部工具 | 原生 commit 日志，按 Agent 身份 |
| LLM 看到的 | 你代码 SELECT 出来再 serialize 的东西 | 文件本身 |
| 能否自托管 | 都能 | 能（开源、Docker） |
| 真正擅长 | 事务、join、结构化应用状态、报表 | 长篇上下文、Agent 可读的知识、多 Agent 协作、scratch 空间 |
什么时候该用 Postgres / Supabase（而不是 puppyone）
如果你真正要做的是结构化的应用数据，用 Postgres / Supabase：
- 任何带行、join、事务、外键、RLS 的东西。
- 应用后端、报表、Auth、计费 —— 任何要求一致性和 SQL 语义的地方。
- 已经在用 SQL 的应用代码做的高并发读写。
- 用
pgvector做生产 RAG 的向量搜索 —— 当 embedding 真的应该挨着结构化数据放的时候。
我们没什么能加给这一块的。Postgres 有 30 年先发优势和巨大生态。用它就好。
什么时候该用 puppyone（而不是 Postgres / Supabase）
如果你真正要做的是给 Agent 一份持久的上下文，用 puppyone：
- Agent 需要读非结构化知识 —— 规格、文档、过往研究、AGENTS.md 风格的指令。
- 多 Agent 工作流，每个 Agent 都应该写到自己 scope 内的路径，并且要有干净的审计。
- 长跑的 Agent，输出需要版本历史和回滚（不仅仅是行上的一个
created_at）。 - 多个 Agent 在同一个工作空间协作 —— researcher 写
/research/，planner 读它，executor 写/output/，互相不踩。 - 任何你曾经手痒在 Postgres 里建过
documents表，带content TEXT、agent_id、updated_at、用来做 revision 的parent_id、还有一坨permissions JSONB的场景 —— 恭喜你正在用 Postgres 重新实现 puppyone。我们已经替你做完了。
什么时候两个一起用（最常见的答案）
生产环境几乎总是这样长的：
- Postgres / Supabase 存应用的结构化数据。 用户、订单、会话、计费、embedding —— 行的世界。
- puppyone 存 Agent 可读的上下文。 规格、文档、物化视图、Agent scratch、生成的报告 —— 文件的世界。
- puppyone 把 Postgres 接成连接器。 特定查询 / 表 / 视图按计划刷新，作为文件夹或文件出现在 Agent 工作空间里。Agent 读
/db/active-customers.csv，而不是去现写一个可能写错的 SQL。 - 要新鲜数字的时候，Agent 通过 MCP / puppyone 暴露的查询工具去打 Postgres。 需要的时候拿现值，不需要的时候用稳定的文件视图。
- Agent 输出（计划、草稿、研究）留在 puppyone 里，带完整版本历史。 只有你认定"稳定"的部分才物化回 Postgres 表，给应用消费。
这个分工有一个干净的规则：行属于 Postgres，叙述属于 puppyone。如果你发现自己在往 Postgres TEXT 列里塞叙述，缝在错的地方。
"为什么不直接把 Agent 上下文放 Postgres？它能装字符串啊。"
能。也确实有人这么做。坏的地方在：
- Postgres 里 diff 不是免费的。 你要么存全量 revision（付存储和写入成本），要么写 CDC，要么接受没历史。puppyone 在存储层就给你 Git 风格 diff，不需要应用代码。
- Postgres 里做 per-agent 权限是 RLS 体操。 能做，但你要为每张表给每个 Agent 写 policy。puppyone 用 per-agent 一个 Access Point 加路径 scope 就解决。
- LLM 母语不是 SQL。 它的母语是文本和文件。每个"Agent 读 Postgres"的项目最终都要写一层翻译（function calling、MCP server、查询模板）。在 puppyone 里 Agent 已经会用这个接口 —— 那就是文件系统。
- Postgres 的行不是 Agent 的工作记忆。 Agent 起草、scratch、重试、分支、丢掉。把这些都放 Postgres 行里，要么爆炸出一堆 versioned row，要么污染生产表。puppyone 给它一个 scratch 是常态、历史是自动的工作空间。
- 物化的文件比 schema 是更密的上下文。 "这是
customers-summary.md" 对模型比 "这是 14 张表的 schema，请写 SELECT" 便宜得多。token 更少，错得更少。
如果你已经在跑 Postgres 或 Supabase，什么都不用动。在 puppyone 里加一个连接器，结构化数据就开始以 Agent 想要的样子出现在它的文件系统里。
"Supabase Vector / pgvector 不就是这回事吗？"
不是，但是互补。
pgvector / Supabase Vector 擅长基于 embedding 的相似度搜索。这是真实有用的原语。它不是 Agent 读文件的地方。embedding 是用来找到对的文档；文档本身还是要存在某个地方。
典型设置是：
- puppyone 存真正的文件（canonical 内容、全文、版本历史）。
- Embedding 存在
pgvector/ Supabase Vector / Pinecone / 你喜欢的向量库里，从 puppyone 的内容算出来。 - Agent 用向量搜，用 puppyone
cat文件 —— 两边的好处都拿到。
（我们另外有一篇 puppyone vs 向量数据库 更深聊这个区别。）
实际怎么"迁"
不存在迁移。Postgres / Supabase 不动。
实际发生的是：
- 保留你已经在跑的东西。 Postgres / Supabase / AlloyDB / Neon —— 同样的故事。
- 在 puppyone 里加 SQL 连接器。 选定要让 Agent 看见的查询 / 表 / 视图，它们出现在
/db/下（或者你挂载的位置），按计划刷新。 - 把 Agent 可读的叙述从 Postgres
TEXT列里搬到 puppyone 文件里。 规格、文档、计划、prompt、AGENTS.md —— 这些不再是数据库行，而是版本化文件。 - 每个 Agent 给一个 Access Point。 Researcher 读
/db/、/specs、/research。Cursor 读/codebase、/db/schema-snapshot/。它们写到自己 scope 内的输出文件夹。 - 生产应用数据留在 Postgres。 任何驱动你真实应用的东西 —— Auth、计费、订单、会话 —— 跟以前一样在 Postgres。
一个月后你会看到：Postgres 装应用和报表依赖的行；puppyone 装长篇、版本化、Agent 可读的上下文；Agent 看到两边，你也不再试图让一个工具干两个活。
FAQ
puppyone 替代我的数据库吗？ 不。你的用户、订单、计费不会到我们这。Postgres / Supabase 干这个。我们存非结构化、Agent 可读、不属于行的那层上下文。
puppyone 能连 Supabase 吗？ 能 —— Postgres 连接器和 Supabase REST / Storage API 都支持。表、查询、storage bucket 都能作为文件夹出现在 Agent 工作空间里。
puppyone 能做 RLS 那种行级安全吗？ 我们不替代 RLS 给你的应用流量用。给 Agent 用，等价物是 Access Point：per-agent 身份加明确的读写路径 scope。同样的思路（每个 principal 最小权限），只不过是在文件层。
Agent 的 prompt 应该存 Postgres 还是 puppyone？ 如果是版本化的、人手写的、给人编辑的 —— puppyone（带 diff 历史的文件）。如果是机器生成的、高吞吐的、append-only 的 —— Postgres。
pgvector 当 Agent 记忆呢？
用 pgvector 做相似度搜索。用 puppyone 存搜出来之后 Agent 真正读的那个文件。它们不是竞品，是分层。
再说一遍 TL;DR
Postgres / Supabase 是给结构化应用数据的数据库。puppyone 是给非结构化 Agent 上下文的文件工作空间。试图用一个干另一个的活，结局要么是丑陋的 documents 表，要么是当作数据库用的文件系统。两个一起跑，行和叙述之间留一道干净的缝。