数据库与迁移
选择 PostgreSQL 部署方式，并在不中断线上应用的前提下发布 Drizzle schema 变更。
已根据启动模板提交
7580470验证。
完成本页后，你将知道各环境应连接哪个数据库、如何把 schema 修改变成可审查的 SQL，以及如何让数据库与应用独立发布。
模板明确选择 PostgreSQL 与 Drizzle，而不是同时维护多种数据库 adapter。本地可由 pnpm setup 在 Docker 中运行 PostgreSQL；生产可选择任意兼容的托管或自建 PostgreSQL，并设置 DATABASE_URL。src/db/schema.ts 是 schema 的唯一事实来源，src/db/migrations/ 中已提交的 SQL 是可部署历史。只有 src/models/** 可以调用 db()。
本地流程
pnpm setup 会创建独立的开发库和测试库。测试数据库名必须包含 test，否则安全保护会拒绝清空数据。
修改 schema 后运行：
pnpm db:generate
pnpm db:migrate
pnpm test:db:setup
pnpm test:db将生成的 SQL 和 meta/_journal.json 与代码一起提交，不要修改已部署的迁移。
生产流程
应用部署不会自动执行迁移。这是默认的安全策略：数据库和应用可以分别观察、重试和发布。
pnpm db:check:prod
pnpm db:migrate:prod生产执行器非交互运行，使用 PostgreSQL advisory lock 并校验 migration checksum。先备份，并采用 expand/contract 变更，使旧代码和新代码都能在 schema 与应用分开发版期间工作。
数据约定
- 数字
id仅供内部使用，公开 API 使用uuid。 - 金额用最小货币单位的整数和币种保存。
- 租户数据含
org_uuid，模型查询必须按组织限定。 - 幂等键与交易号有数据库唯一约束。
- 模板有意避免大范围外键耦合，因此删除顺序和引用检查由服务与生命周期策略管理。
- 预约还使用 PostgreSQL exclusion constraint 防止已确认或保留时段重叠。
上生产前要做的选择
- 决定由 CI 发布任务还是运营人员执行迁移，不要让每个 Web 实例自动运行。
- 制定与数据价值匹配的备份与恢复策略；迁移锁不能替代备份。
- 保留模板较轻的外键策略，或在明确删除与保留规则后增加更严格约束；两种选择都必须保证租户隔离。
- 零停机发布优先使用 expand/contract。一步完成的破坏性重命名更简单，但会绑定 schema 与代码发布，并让回滚不安全。
当 pnpm db:check:prod 显示预期的待执行集合、备份已更新、迁移已在 staging 副本验证，并且发布期间新旧应用版本都能运行时，才可以执行生产迁移。
修改生产数据契约前，请阅读模板内的 docs/database.md 与 DEPLOYMENT.md。