AI原型的数据库债，迟早要还

原型三周上线很爽，但数据库这笔债，会在你拿到第一批真实用户的那天开始计息。The New Stack 最近的一篇文章把话挑明了：AI 原型阶段的数据库选型，可能回头反咬你一口——开发者为了尽快跑起来，随手选一个最容易上手的库，等业务长出来，迎接他们的就是一场代价高昂的 replatforming（重平台化）。

这不是什么新故事，但在 AI 应用动辄周更的节奏里，它正在被成倍放大。

🚀 三周上线的快感，是怎么欠下的

选库快，是原型阶段的理性选择，不是工程师的错。

一个典型的场景：团队拿到一个 AI 应用需求，要 RAG、要会话记忆、要语义检索，demo 两周内要给客户看。这个时候没人会花一周去做容量规划——打开托管平台，注册、连串、灌数据，一个下午就能跑通。Supabase、Neon 这类 Serverless 服务，或者一个开箱即用的托管向量库，都是这个阶段的天选之子。那篇文章的核心论据之一是：开发者建 AI 原型时，天然想用最快速度跑起来；但跑得太快，代价随后就到——文章把这一现象归因于原型期与生产期的激励错位，而不是团队的能力问题。

问题在于，原型期的「快」，是通过跳过一系列决策换来的：事务边界没设计、嵌入模型随手挑了个默认版、数据访问层和某个厂商的私有 API 焊死在一起。这些跳过的决策不会消失，只会变成技术债挂在账上。

这种债并不是理论推演，而是有公开案例可查的。Uber 在 2016 年发布的官方博客《Why Uber Engineering Switched from Postgres to MySQL》详细记录了他们在业务大规模扩张后，因 Postgres 在其负载下的架构限制而被迫整体切换到 MySQL 的过程——这场迁移动用了多年时间和大批工程资源，仅仅是为了纠正早期「够用就好」的选型。Discord 也在 2023 年的官方博客中公开了把数万亿条消息从 Cassandra 迁往 ScyllaDB 的全过程：分阶段回填、双写验证、灰度切换，整个项目持续数月，而这还只是在同属宽列存储的两套系统之间搬家。当原型期的选型和生产期的需求出现结构性错配时，没有一家规模化的公司能逃过这笔账。

产业逻辑很简单：原型期的选型标准是「到 demo 的距离」，生产期的标准是「到五年后的距离」，两把尺子量出来的赢家，往往不是同一个。而数据库的特殊性在于，它是全栈里最难换的那一层——改个前端框架是重构，换数据库是搬家。

⚠️ 迁移不是搬家，是重建

最贵的技术债，藏在数据层。

应用层的重构，坏消息是代码要改；数据层的重构，坏消息是你的历史数据、业务语义、下游依赖全都要跟着动。文章标题里那句「could come back to haunt you」，翻译成工程语言就是：replatforming 不只是把数据从一个库倒进另一个库，而是要重新审视模式设计、事务语义、索引策略、嵌入版本，甚至业务里那些「当年图省事没写进文档」的隐式约定。

成本有多大？Gartner 给出的一个被行业广泛引用的数字是：约 83% 的数据迁移项目会失败，或者严重超出预算与工期。Discord 的公开博客也印证了一个普遍规律：迁移工期的估算，漏掉最多的往往不是搬运时间，而是「发现旧库里埋了多少坑」的时间——他们的迁移计划在执行中经历了多轮返工，才覆盖到所有历史数据形态。双写、影子读、灰度切流、回滚演练，每一步都是真金白银的工程投入，而且这段时间里团队的主线业务基本停摆。

这条链路里最扎心的一点是：从 C 到 G 的每一步，花的都是「原型期省下来的时间」的利息，而且是复利。更糟的是，AI 应用的数据层还有一个传统应用没有的变量——嵌入模型的版本演进。OpenAI 在 2024 年初发布 text-embedding-3 系列并宣布旧版 ada-002 进入弃用流程时，官方文档明确指出不同模型产生的向量彼此不可比——这意味着换一次 embedding 模型，就要全量数据重新向量化，本身就是一次隐形的重平台化。如果原型期没把 embedding 版本化管理起来，这一天迟早要来。

判断其实很清楚：数据库决策的账，不能只算「上线要多快」，还要算「搬走要多贵」。前者是显性成本，后者是隐形负债，而负债总是到期才显形。

🧭 一张四象限图，看清谁是过客谁是归宿

不是所有库都值得托付五年。

既然选型有代价，那就需要一个框架来判断：哪些库是「顺手一用的过客」，哪些是「可以长期住下去的家」。下面这张四象限图是作者基于公开资料和工程经验整理的个人判断框架，各产品的具体位置带有主观成分，仅供选型时参考坐标、不应视为客观排名——但把技术门槛和长期承载价值摆到两个轴上的思考方式，是通用的。

这张图的产业含义值得展开说。右上角的 PostgreSQL 加 pgvector 之所以被越来越多 AI 团队当成默认起点，不是因为它在某个单项上最强，而是因为它把关系数据、事务和向量检索收进同一个事务边界——AI 应用的痛点从来不是「缺一个向量库」，而是「结构化数据和语义数据割裂在两套系统里」。

右上角要付出的代价是技术门槛：你得自己管扩容、管调优、管高可用。于是左上角的 Serverless 托管关系库（Neon、Supabase 这类）成了很好的折中——底座还是 Postgres 生态，迁移路径天然顺畅，就算将来要搬到自管集群，协议和 SQL 大体通用，这类「托管的开放生态」比「托管的私有引擎」在退路上的差距是数量级的。Supabase 等厂商的公开案例库中，大量团队正是沿着「原型用托管 Postgres、业务长大后迁往自管集群」这条路径完成扩容的，靠的正是开放生态的协议兼容性。

左下角是最危险的区域：为了 demo 快，拿内存缓存或者某个单机嵌入式库当主库，上线那天就是倒计时开始的那天。右下角的存量玩家（不少传统商业库）则处在另一个尴尬里——承载能力尚可，但生态和 AI 工作流的贴合度在掉队。

从近两年公开的趋势看——pgvector 在 GitHub 上的星标数持续高速增长、主流云厂商纷纷为托管 Postgres 补上向量扩展、各大 AI 应用模板默认内建 Postgres——「能用开放生态就用开放生态」正在取代「谁快用谁」，成为 AI 团队选库的第一原则。原因不难理解：前者保留的是选择权，后者典当的是选择权。

🛠️ 把迁移成本前置到第一天

治技术债最好的时机，是写第一行代码之前。

承认现实：原型期就是要快，这不丢人。真正的问题不是「选了不完美的库」，而是「选的时候没给未来的自己留后门」。工程上有几个动作，成本极低，但能在 replatforming 那天省下几倍的钱。

把这几条落地成一个可执行的节奏，大概是这个样子：

三个月起步的迁移周期，对应的是当初「一下午选完库」的决策瞬间——这个杠杆比失衡到近乎荒诞。真正划算的做法，是把一部分迁移成本前移成原型期的几分钟决策：

其中最容易被忽视的是最后一行：负载画像不是生产期的事，原型期就该开始记。真实的读写比例、峰值形状、数据增长曲线，这些数据是你将来和任何厂商谈判、做任何容量决策的唯一底气。没有画像的选型，本质上是闭眼赌博——赌赢了叫技术直觉，赌输了叫 replatforming。

还有一条值得钉在墙上的核心提醒：快是原型期的正当需求，但「快」和「可迁移」并不冲突。选择开放生态、保留抽象层、版本化关键状态，这三件事加起来可能多花一天，换来的却是将来搬家的自由。

小结

The New Stack 那篇文章的标题里有个词很准：haunt（反噬）。数据库决策的反噬从来不在决策当天，而在六个月后、真实用户涌入的那个凌晨。Uber 用一场多年期的数据库大迁徙、Discord 用一次数月之长的万亿消息搬迁、Gartner 用一个 83% 的失败率数字，反复验证着同一件事：数据层的债，迟早要还，而且带利息。AI 应用让数据层的复杂度陡增，也让原型与生产之间的鸿沟变宽了。务实的态度不是拒绝快，而是在快里为慢留出退路：开放生态打底、抽象层隔离、嵌入版本化、负载画像从第一天开始记。可以预见，随着 AI 应用进入洗牌期，replatforming 会从个别团队的救火行动，变成一个显性的工具与服务平台类目——谁把迁移做成一等产品力，谁就接住这波还债潮。

参考信源

• The New Stack：《AI 原型阶段的数据库选型可能反噬生产环境》（原文出处）
• Uber Engineering Blog：《Why Uber Engineering Switched from Postgres to MySQL》（2016）
• Discord Engineering Blog：《How Discord Migrated Trillions of Messages to ScyllaDB》（2023）
• Gartner：数据迁移项目成功率调研（被行业广泛引用的 83% 数字）
• OpenAI 文档：text-embedding-3 系列发布说明及嵌入模型不可比性说明