Postgres 迁移彩排
数据库上线前提交迁移脚本，先看到锁冲突时间线、危险语句和可回滚的执行顺序。
初创团队准备执行 PostgreSQL 迁移前，上传 SQL、当前表结构，以及脱敏后的行数、索引和访问量统计。产品不会直接碰生产库，而是在临时副本中重放迁移，并模拟并发读写、锁等待和失败后的回滚路径。
结果页用一条锁等待时间线展示哪条语句会卡住写入、哪些表会被拖慢，以及不同执行顺序的影响。团队可以点进危险语句，查看它为何会锁表、可能影响哪些接口，以及是否应拆成新增字段、后台回填、切换读取和延后删除几步。
选定方案后，系统生成按顺序执行的操作卡。每张卡写明执行命令、开始前要确认的指标、允许观察多久，以及达到什么条件必须停止或回滚。值班同事可以在卡片上记录实际耗时，作为下一次迁移的参考。
起步版本聚焦常见 DDL 迁移和锁风险，不替团队自动上线，也不替代备份与恢复演练。它先把“应该没问题”的迁移，变成能在发布前看见风险和撤退路径的彩排。
为什么是现在
7月22日，这篇指南登上 Hacker News；截至7月23日位列第6。S1 它会把改表团队的注意力推向锁写入风险，也暴露出静态建议看不见等待链和撤退顺序。S2
目标用户
核心用户是没有专职 DBA 的初创后端负责人、平台工程师和当周值班者。触发点是迁移已经写完，发布排期也已确定，却没人能判断锁会排多久。此时改脚本仍来得及，直接上线的代价却已很高。值班者需要的不只是风险标签，而是一套可照着执行和撤退的顺序。
最小切入点
入口接受迁移 SQL、当前 schema，以及脱敏后的表级统计。服务在隔离的 PostgreSQL 实例中还原结构，并按行数生成占位数据。用 pgbench 自定义脚本制造并发读写。再从 pg_locks 和 pg_stat_activity 采集等待关系。S2 范围先收在常见 ALTER TABLE、索引和约束变更。结果先呈现锁模式、阻塞链、耗时和失败点，不估算真实接口延迟。执行方案用确定性规则拆成扩展、回填、切换和收缩步骤。非事务型操作单独标记，并要求用户填写可验证的撤退动作。
以小博大
先做 GitHub App，在迁移 PR 上回贴静态锁摘要和一键彩排链接。免费层运行小型隔离实例，并公开常见 DDL 的风险案例库。开发者可围绕真实迁移复盘写短文，附可导入的演练模板。再适配常见迁移目录结构，减少团队调整现有流程的阻力。
竞品与缝隙
怎么赚钱
按团队订阅，依据每月彩排次数分档。静态检查免费，托管并发彩排、执行卡和历史记录收费。
反方视角
最大的风险不是跑不起来，而是跑得太像真相。表级行数和访问量无法还原查询形状、热点键、长事务、硬件差异和后台任务。彩排可能漏掉生产阻塞，也可能把无害操作判得过重。若结果被当成上线保证，反而会制造错误安全感。很多 DDL 的撤退也不是简单执行反向 SQL。数据回填和应用版本切换还牵涉业务兼容。团队还要承担 schema 外泄顾虑，以及构造临时库的等待和算力成本。若已有高保真 staging、成熟 DBA 和迁移手册，新工具可能只会重复流程。