database

用途

该技能用于在构建 SaaS 应用时处理数据库相关任务：选择数据库、设计 Schema、配置 Supabase 或其他数据库、编写查询、处理迁移、修复问题。资料将重点放在“数据库与数据建模”上，并明确指出：早期做出的 Schema 决策后期修改成本很高，因此需要在早期把关系设计正确。

核心原则

资料列出以下原则：

选择与你的托管平台匹配的数据库，不要对抗默认配置。
Schema 设计就是产品设计，尽早把关系确定好，后期迁移代价大。
每个 SaaS 都是多租户，每张表都需要一种隔离客户数据的方式。
从简单开始。在 MRR 为 0 到 1 万美元阶段，不需要 Redis、Elasticsearch 或数据仓库。
行级安全（Row Level Security，RLS）不是可选项。一个客户泄露看到另一个客户的数据会摧毁信任。

数据库选型

资料给出的选型建议是：使用 Supabase（PostgreSQL），除非有特定理由不用。它在一个服务中同时提供数据库、认证、存储、实时和 RLS。

按平台对应的默认数据库（资料原文表格内容）：

Supabase：内置 PostgreSQL，建议使用，称其为大多数 SaaS 的最佳选择。
Vercel + Prisma：Supabase、Neon 或 PlanetScale，建议选一个并坚持使用。
Lovable：集成的 Supabase，建议不要对抗集成。
Replit：SQLite 或 Supabase，生产级 SaaS 用 Supabase。
Railway：PostgreSQL，建议使用。
Firebase：Firestore，如果已经在 Google 生态中则可以用。

何时可能需要其他方案（资料原文表格内容）：

全文搜索：Supabase 有内置文本搜索，只有不够用时才考虑 Algolia/Typesense。
缓存：先不加，只有在出现可测量的延迟问题时才加 Upstash Redis。
文件存储：Supabase Storage、Cloudflare R2 或 S3。
分析/报表：先用 Supabase 视图或物化视图，数据仓库留到 MRR 超过 1 万美元之后。

Schema 设计

资料称每套 SaaS 都需要三张表：users（谁使用应用）、organizations（多租户）、memberships（谁属于哪个组织）。三张表的建表 SQL 均为 PostgreSQL 语法，包含 UUID 主键、外键级联删除、角色检查约束和唯一约束。

加入核心业务对象时，资料要求把它连接到组织：包含 org_id 外键（非空、级联删除）、created_by 外键、业务字段、状态字段和时间戳，并要求始终为 org_id 建索引以支持多租户查询。

资料提供的自然语言提示模板为：向 AI 描述 SaaS 产品、列出核心对象、说明用户属于组织且每个组织拥有自己的数据，并要求使用 Supabase（PostgreSQL），输出表定义（含类型与约束）、外键关系、常用查询索引和 RLS 策略。

RLS

资料说明 RLS 确保用户只能看到自己组织的数据，并提供基本模式：对每张含客户数据的表启用 RLS，分别创建 SELECT 和 INSERT 策略，通过 memberships 表与 auth.uid() 关联，限制到用户所属的 org_id。

资料给出的 RLS 清单要求对每张含客户数据的表：启用 RLS、限制 SELECT、INSERT、UPDATE、DELETE（或阻止删除）到用户所属组织，并测试“用户 A 不能看到用户 B 的数据”。

迁移

资料定义迁移为对 Schema 的版本控制变更，类似数据库结构的 git。最佳实践包括：绝不直接编辑生产表，始终使用迁移；每个迁移只做一件事，例如“给 projects 添加 status 列”而不是“重构一切”；迁移是前向的，不要删除旧迁移，而是添加新迁移；先在分支数据库上测试，Supabase 提供数据库分支功能。

提示模板：要求 AI 编写 Supabase 迁移，提供当前表结构，输出 SQL 迁移和必要的 RLS 策略更新。

常见模式

软删除：不要硬删除记录，而是用 deleted_at 列标记；更新 RLS 以排除软删除行。
审计日志：用 audit_log 表跟踪谁改了什么，包含 org_id、user_id、action、table_name、record_id、changes（jsonb）和 created_at。
状态工作流：用 check 约束限定有效状态值。

性能基础

索引规则：始终为外键建索引（org_id、user_id 等）；为经常过滤或排序的列建索引；不要给所有列建索引，因为每个索引都会拖慢写入。

查询建议：只选择需要的列，不要 SELECT *；列表使用分页（LIMIT/OFFSET 或基于游标）；对复杂的重复查询使用数据库视图；在查询前用 explain analyze 检查性能。

常见错误与修正

资料列出：不从开始就做多租户（修正：从第一天起给每张表加 org_id）；跳过 RLS（修正：对每张含客户数据的表启用）；直接编辑生产 Schema（修正：始终使用迁移）；把文件存在数据库里（修正：用 Supabase Storage 或 S3）；外键无索引（修正：为每个 org_id 和 user_id 列建索引）；所有东西塞进一张大表（修正：用关系规范化到多张表）；没有 created_at/updated_at（修正：给每张表加时间戳）；硬删除记录（修正：用软删除的 deleted_at 列）。

成功标准

资料描述的成功状态为：Schema 干净、表关系清晰；每张面向客户的表都有经过测试的 RLS 策略；迁移被跟踪并版本化；当前规模下查询速度快；能够向承包商或 AI 工具清楚解释数据模型。

限制

资料未提供该技能的具体安装命令、支持的平台版本、收费方式、价格或效果数据。

技能介绍

用途