Prisma Migrate 放进存量团队前要先算清楚代价

2022 年 Prisma 热度越来越高，很多团队开始认真讨论要不要把 Prisma Migrate 引进来。但对已经跑在 Sequelize 或自建 migration 体系上的项目来说，这不是“装个新工具”那么简单，它会牵涉数据库演进方式、代码生成流程和团队习惯一起变化。

我比较看重的判断点有三个。第一，现有 migration 历史是否足够干净，能不能顺利映射到新的 schema 管理方式；第二，团队是否真的需要 Prisma 提供的那套开发体验；第三，引入之后是不是会同时维护两套数据库认知模型。

如果答案并不明确，我通常不会建议在存量系统里贸然切换。因为 migration 工具一旦变成“双轨制”，后面排查表结构差异会非常痛苦。

Prisma Migrate 适合的是愿意整体接纳它工作流的团队，而不是把它当成局部增强件随手塞进现有系统。先把代价算清楚，再谈是否值得迁。

为什么这类问题总会在线上阶段突然变贵

围绕「Prisma Migrate 放进存量团队前要先算清楚代价」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。