主题颜色
产品数据层选型
产品数据层选型，是决定 AI 辅助构建的产品如何存储、演进和管理结构化数据的过程。原始材料以数据库为重点，但对本知识库更持久的价值在于工作流边界：不要让智能体随意发明持久化方案；应把数据层明确写进产品规格。
核心决策
对大多数包含用户、订单、项目、订阅或其他强关联记录的小型 SaaS 产品，优先从 PostgreSQL 开始，而不是灵活的 NoSQL 存储。原因并非传统惯性，而是产品数据通常存在关系、约束和报表需求。
当团队主要需要托管式 PostgreSQL 时，原文推荐 Neon；当团队希望获得认证、存储、自动生成 API 和边缘函数等更完整的后端套件时，则推荐 Supabase。若运营稳定性或平台整合比上手便利更重要，云厂商数据库仍然是有效选择。
设计循环
实际工作流是：
- 从产品规格中提取实体及其关系。
- 只有在数据形态清晰之后才选择存储服务。
- 将开发数据库与生产数据库分开。
- 通过迁移管理模式变更，不要手工修改生产环境。
- 使用 Drizzle 或 Prisma 等 ORM，使代码类型与数据库模式保持一致。
- 配置管理界面或数据库工具以获得运营可见性，并加上认证和最小写入权限。
这与规格驱动开发直接相连：数据库模式是实现契约的一部分，而非事后补充。
迁移纪律
迁移是数据库结构的版本控制层。没有迁移，开发者会手工改表，不同环境逐渐漂移，生产故障也难以追踪。有了迁移，每次模式变更都会成为可重放的记录。
在 AI 辅助工作中，迁移是一道护栏。智能体可以提出模式变更，但持久产物应是已检查的迁移文件和更新后的模式定义，而不能只是通过 UI 修改过的数据库。
工具边界
| 选择 | 适用场景 | 风险 |
|---|---|---|
| Neon | 主要需要具有无服务器友好体验的托管式 PostgreSQL。 | 不提供 Supabase 那样完整的后端套件。 |
| Supabase | 希望将数据库、认证、存储、API 和后端服务放在一起。 | 团队可能为实际并未使用的功能承担复杂度。 |
| Drizzle | 希望使用贴近 SQL 的 TypeScript 模式，并适配轻量无服务器环境。 | 要求更熟悉 SQL。 |
| Prisma | 希望快速上手、获得易用的生成客户端和成熟文档。 | 会引入自有模式语言和客户端生成流程。 |
| TablePlus／管理 UI | 需要运营检查或手工修复数据。 | 直接编辑需要严格的访问控制和审计纪律。 |
文件存储边界
部署运营材料还补充了一条重要的相邻规则：不要把数据库当作所有持久产品产物的存放处。结构化记录属于数据库；生成的图片、音频、视频、PDF、头像和用户上传文件通常属于云对象存储。
AI 产品文件持久化把数据库用作元数据和引用存储：保存永久对象 URL、用户 ID、提示词和时间戳，实际字节则放在对象存储中。这样既保持数据层可查询，又不会把数据库变成文件服务器。
对智能体简报的启示
要求 AI 编程智能体添加持久化时，提示词应明确：
- 现有模式，或应去哪里检查；
- 本次涉及哪些实体和关系；
- 是否必须生成迁移；
- 是否应复用 Drizzle、Prisma 或其他现有数据层；
- 哪些环境可以安全修改；
- 哪些管理操作只读、可编辑或被禁止。
这让智能体任务简报在数据库工作中变得具体，也降低智能体另建平行数据层、向客户端暴露密钥或绕过迁移历史的概率。