Next.js 数据库选型指南：PostgreSQL、MySQL、MongoDB 与云服务全面对比

凌晨两点,我盯着 Vercel 控制台上的 “Add Database” 选项,光标在 Postgres、MySQL、MongoDB 之间来回移动。项目要在48小时后上线,我却还在纠结用哪个数据库。打开浏览器,10个标签页都是技术文章,有人说 Supabase 免费额度大方,有人说 PlanetScale 性能爆表,还有人说 MongoDB 最适合 Next.js。

越看越迷茫。

说实话,我当时真的挺崩溃的。不是因为这些数据库难用,而是选项太多了——每个看起来都很好,每个又都有局限性。更要命的是,一旦选错,后期迁移的代价可能比重写代码还高。

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

如果你也正在经历这种纠结,这篇文章就是为你准备的。我会用最直白的方式,帮你理清 PostgreSQL、MySQL、MongoDB 三大数据库的本质区别,以及 Vercel Postgres、Supabase、PlanetScale、MongoDB Atlas 这些云服务到底该怎么选。

不讲那些虚的。

看完之后,你只需要回答3个问题,就能快速做出决策。

先搞懂基础——三大数据库的本质区别

PostgreSQL vs MySQL vs MongoDB：不只是关系型和非关系型

大家通常会说: PostgreSQL 和 MySQL 是关系型数据库,MongoDB 是 NoSQL。这没错,但这样的分类对选型没啥帮助——你还是不知道该选哪个。

我换个角度聊聊它们的性格。

PostgreSQL 就像那种功能全面的瑞士军刀。它不仅支持传统的关系型数据,还能处理 JSON、全文搜索、地理空间数据,甚至可以写复杂的存储过程。你能想到的高级功能,它基本都有。但这也意味着学习曲线稍陡——功能多,选择就多,新手容易懵。

性能方面,PostgreSQL 在复杂查询上表现优秀。有测试显示,涉及多表连接的场景,PostgreSQL 比同类数据库快30%左右。但这是有代价的:配置不当的话,它的资源占用会比 MySQL 高一些。

MySQL 则是那种稳定可靠的老伙计。它轻量、成熟、文档齐全,社区资源多到爆炸——遇到问题基本搜一下就能找到解决方案。很多老项目用它,就是图个省心。

不过 MySQL 也有短板。它是垂直扩展的,简单说就是:机器性能到顶了,你只能换更强的机器,没法像 MongoDB 那样横向加服务器。对于流量不太大的项目,这不是问题;但如果你做的是高并发应用,这可能会成为瓶颈。

MongoDB 完全不一样。它存的不是表,是 JSON 格式的文档。这带来了极大的灵活性——你随时可以给某个文档加字段,不用像关系型数据库那样先改表结构。对于需求变化快的项目,这简直是救命稻草。

我之前做过一个内容管理系统,文章的自定义字段经常变:今天加个”阅读时长”,明天加个”相关推荐”。如果用 MySQL,每次改需求都得 ALTER TABLE,还要考虑历史数据兼容。换成 MongoDB 之后,直接在代码里加字段就行了。

但 MongoDB 也不是银弹。复杂的多表关联查询?它做不了,或者说做起来很别扭。需要严格的事务一致性?它支持,但没有关系型数据库那么自然。

所以你看,选数据库不是选”好”或”坏”,而是选”合不合适”。

什么时候该用哪个？三个判断维度

好,既然没有绝对的”最好”,那怎么判断?我给你三个实用的维度。

维度1: 数据关系有多复杂

这是最核心的判断标准。

你的项目是不是有大量的”这个关联那个”的逻辑?比如电商系统:用户有订单,订单有商品,商品有分类,分类又有标签…这种多层嵌套、需要频繁 JOIN 查询的场景,PostgreSQL 或 MySQL 是首选。关系型数据库就是为这种场景设计的,外键约束、事务一致性都是现成的。

反过来,如果你的数据结构比较扁平,或者说每条数据相对独立,MongoDB 会让你轻松很多。典型的例子:博客系统的文章和评论。每篇文章就是一个完整的 JSON 文档,评论可以直接嵌套在文章里,或者单独存储但关联很简单。这种情况下,MongoDB 的灵活性就是优势。

维度2: 需求变化有多频繁

产品经理三天两头改需求?那 MongoDB 能救你一命。

我见过太多项目,一开始用关系型数据库设计得很完美,字段、索引、约束都规划好了。结果两周后产品说:“我们要加个用户标签功能。” 再两周:“标签要支持多选。” 再两周:“标签要有层级关系。“每次改需求,数据库都要跟着改,迁移脚本写到吐血。

用 MongoDB,这些都不是事儿。直接在代码里加字段,旧数据兼容性用代码逻辑处理就行。当然,这也意味着你要在代码层面做更多的数据校验——数据库不会帮你兜底了。

但如果你的业务逻辑已经很稳定,或者说你在做的是那种”规则明确、流程固定”的系统(比如财务软件、ERP),那关系型数据库的约束反而是优势。它能在数据库层面就防止错误数据写入,代码里少操很多心。

维度3: 团队习惯用什么

别小看这一点。

技术栈没有绝对的高低,但团队的熟练度差距是真实存在的。如果你们团队都是写 SQL 长大的,非要用 MongoDB,学习成本和踩坑时间可能比项目本身还长。反过来也一样。

我之前在一个创业团队,大家都是 JavaScript 背景,对 SQL 不太熟。那时候用 PostgreSQL,写复杂查询经常要查文档,索引优化更是一头雾水。后来换成 MongoDB + Mongoose,开发效率直接翻倍——因为 Mongoose 的 API 和 JavaScript 对象操作几乎一样,不用切换思维模式。

当然,这不是说该迁就团队的舒适区。如果项目确实需要关系型数据库,那该学还是得学。但如果两种方案都能实现需求,选团队更熟悉的那个,绝对没错。

云服务大混战——Vercel Postgres、Supabase、PlanetScale、MongoDB Atlas 怎么选

云服务对比：不只是看价格

数据库选好了,接下来就是云服务的坑了。

Vercel Postgres、Supabase、PlanetScale、MongoDB Atlas…每个看起来都很香,但魔鬼藏在细节里。我一个个说。

Vercel Postgres:一键部署的诱惑

如果你的项目本来就部署在 Vercel 上,Vercel Postgres 几乎是最省心的选择。点几下鼠标,数据库就配好了,环境变量自动注入,延迟低到吓人(基准测试显示常常<10ms)。

但它也有明显的短板:功能相对简单。没有内置的用户认证系统,没有存储服务,也没有实时订阅功能。如果你只是要一个单纯的 PostgreSQL 数据库,它很完美;如果你想要一个”全家桶”,还得自己搭配其他服务。

定价方面,免费版给 256MB 存储,对于小项目够用。付费从 $20/月起,不算便宜,但考虑到它和 Vercel 部署的深度集成,这钱花得值。

Supabase:开源界的全能选手

Supabase 是我个人最喜欢的选择之一。为啥?因为它不仅是个 PostgreSQL 数据库,还自带用户认证、文件存储、实时数据订阅,甚至还有一个挺好用的后台管理界面 Supabase Studio。

免费额度也很大方:500MB 数据库 + 1GB 存储,对于个人项目和 MVP 来说绰绰有余。我见过不少独立开发者,整个产品跑在 Supabase 免费版上,完全没问题。

性能呢?老实讲,不如 PlanetScale。有个基准测试显示,Supabase 的 QPS(每秒查询数)大约在 5000 左右,而 PlanetScale 能到 17000。但对于大部分中小型应用,这个性能差距感知不强。而且 Supabase 用的是标准的 PostgreSQL,迁移起来也方便。

唯一要注意的是,如果你的流量突然暴涨,Supabase 的连接池可能会成为瓶颈。不过它提供了 Pooler 功能,专门解决 Serverless 环境下的连接数问题,配置一下就行。

PlanetScale:性能怪兽,但有代价

PlanetScale 的性能确实强。刚才说的基准测试,它的 QPS 能达到 ~17000(混合读写)、~35000(纯读),几乎是 Supabase 的三倍。如果你做的是高并发应用,这个差距很明显。

它还有个很酷的功能:数据库分支管理。就像 Git 一样,你可以给数据库创建分支,在分支上测试 schema 变更,确认没问题再合并回主分支。对于团队协作来说,这简直是神器。

但它也有几个硬伤:

第一,不支持外键。这对于依赖外键约束的项目来说是个大问题,得在应用层自己处理数据一致性。

第二,贵。PlanetScale 在 2024 年取消了免费计划,现在起步价就是 $34/月。对于预算紧张的个人开发者或创业团队,这不是小数目。

所以我的建议是:如果你的项目确实需要极高的并发性能,或者团队规模比较大需要数据库分支管理,PlanetScale 值得投资。否则,还有更性价比的选择。

MongoDB Atlas:灵活性的代价是学习曲线

MongoDB 的官方云服务,免费版给 512MB,比 Vercel Postgres 多一倍,跟 Supabase 差不多。部署也方便,全球多区域都支持。

如果你选了 MongoDB 作为数据库,Atlas 几乎是默认选择——官方出品,稳定性和功能更新都有保障。

但 NoSQL 的学习曲线还是要考虑的。如果你之前一直写 SQL,切换到 MongoDB 的聚合查询(Aggregation Pipeline)会有点不适应。还有就是,虽然 MongoDB 支持事务,但它的事务实现没有关系型数据库那么自然,某些场景下性能也会打折扣。

Vultr - 高性能 NVMe 云服务器，32 个全球节点可选，支持一键部署 Docker

查看定价 →推广

还有个隐藏的坑:带宽费用。MongoDB Atlas 的定价是按存储和请求量计费的,如果你的应用查询频繁,带宽费可能比数据库本身还贵。我有个朋友之前用 Atlas,月底看账单发现带宽费占了 60%,吓了一跳。后来优化了查询逻辑+加了缓存,才把成本压下来。

这里给个性能对比表,方便你快速对照:

隐藏成本：不只是看月费

这部分特别重要,因为很多人就是栽在这里。

账单上的数据库月费,只是冰山一角。真正让你心疼的,往往是那些隐藏的费用。

连接数限制:Serverless 的噩梦

Next.js 部署在 Vercel 或其他 Serverless 平台上,每个请求都会启动一个新的函数实例。如果每个实例都创建一个数据库连接,几百个并发就能把数据库连接池撑爆。

传统的连接池方案在 Serverless 环境下基本失效。你会看到这样的错误信息:“Too many connections” “Connection pool exhausted”…凌晨三点被告警吵醒的感觉,我不想再经历一次。

好消息是,大部分云服务都意识到这个问题了。Supabase 提供了 Pooler 模式,PlanetScale 自带连接池,Vercel Postgres 因为是自家的所以做了深度优化。但 MongoDB Atlas 在这方面就需要你自己处理,要么用连接池库,要么忍受连接数告警。

带宽费用:查询频繁的隐形杀手

数据库和应用不在同一个区域?恭喜你,每次查询都要跨区域传输,带宽费蹭蹭往上涨。

MongoDB Atlas 在这方面最明显。因为它是按请求量和数据传输量计费的,如果你的应用查询频繁、返回的数据量又大,带宽费很容易超过数据库本身的费用。

解决方案:

1. 尽量把数据库和应用部署在同一个区域
2. 查询时只返回必要的字段,别 SELECT *
3. 加缓存层,减少重复查询

扩展成本:不可忽视的长期投资

PlanetScale 和 Supabase 都是按存储量和连接数阶梯收费的。刚开始可能在免费或低价档位,但随着数据增长,费用会跳档上涨。

举个例子,Supabase 的免费版是 500MB,超了之后 Pro 版是 $25/月包含 8GB。如果你的数据增长到 10GB,那就要补差价。这个差价看起来不多,但如果没提前规划,突然发现月账单翻倍还是挺心疼的。

PlanetScale 更夸张,它的定价是按行数计费的。起步档 $34/月包含 100 亿行读和 5000 万行写,超了之后按量加钱。对于高频写入的应用,这个成本会涨得很快。

迁移成本:选错了之后的代价

这是最容易被忽略的成本。

数据库迁移不是简单的数据搬家,还涉及 schema 转换、代码适配、测试验证…小项目可能一两天搞定,大项目能折腾几个月。

我之前有个项目,一开始用 MongoDB 图方便,后来业务复杂度上来,各种复杂查询写得头疼,决定迁移到 PostgreSQL。光是设计新的关系型 schema 就花了一周,迁移脚本调试了半个月,测试环境和生产环境分别上线,前后折腾了快两个月。

所以我现在的建议是:如果不确定,优先选主流的、容易迁移的方案。比如用 ORM 框架(Prisma、Drizzle)做数据库抽象,这样即使将来要换数据库,起码代码层面的改动能少一些。

决策框架——3个问题定方案

问题1：你的项目是什么类型？

前面讲了这么多技术细节,现在回到最实际的问题:你到底该选哪个?

我给你一个简单粗暴的决策框架。不用记那些复杂的性能参数,就问自己三个问题。

第一个问题:你的项目是什么类型?

这直接决定了80%的选择。

个人项目 / MVP 快速验证

预算有限,但想要功能全面?→ Supabase

免费额度 500MB + 1GB 存储,还自带用户认证和实时订阅,对于个人开发者来说简直是梦想配置。我见过太多独立开发者,整个 SaaS 产品就跑在 Supabase 免费版上,几千用户完全没问题。

如果你对 NoSQL 更熟悉,或者项目的数据结构特别灵活?→ MongoDB Atlas

512MB 免费版,适合内容管理系统、博客、日志收集这类数据结构不固定的项目。

创业公司 / 小团队项目

已经在 Vercel 部署,追求开发效率?→ Vercel Postgres

虽然免费版只有 256MB,但考虑到它和 Vercel 的深度集成,环境变量自动注入、边缘网络加速这些能省你不少配置时间。创业团队最贵的是时间,不是那 $20 月费。

需要用户认证、文件存储这些全家桶功能?→ Supabase

它不只是个数据库,是个完整的后端解决方案。Authentication、Storage、Edge Functions 都是现成的,能省下好几周的开发时间。

企业应用 / 高并发场景

用户量大,对性能有严格要求?→ PlanetScale

QPS ~17000 不是开玩笑的,而且数据库分支管理对于大团队来说真的很实用。$34/月起步价对于有稳定收入的企业来说不算什么。

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

但要注意,PlanetScale 不支持外键,如果你的业务逻辑严重依赖外键约束,可能要重新考虑。

内容站 / 博客 / 媒体平台

数据结构灵活,查询相对简单?→ MongoDB Atlas

文章、评论、标签这些内容数据,用文档型数据库存储非常自然。而且 MongoDB 的全文搜索功能比关系型数据库方便多了。

需要实时评论、实时通知?→ Supabase

它的 Realtime 功能是基于 PostgreSQL 的 Change Data Capture,配置一下就能实现实时订阅,不用自己搭 WebSocket。

问题2：你的预算和规模？

钱的问题,总是要面对的。

零预算阶段(纯免费方案)

Supabase(500MB + 1GB 存储) 或 MongoDB Atlas(512MB) 是你仅有的选择。

Vercel Postgres 虽然也有免费版,但只有 256MB,增长空间有限。PlanetScale 直接没免费版,pass。

我的建议:如果项目可能需要用户认证或文件上传,优先 Supabase。如果是纯数据存储,MongoDB Atlas 更灵活。

小预算阶段(月预算 <$50)

Supabase Pro($25/月) 或 Vercel Postgres($20/月起) 都在这个范围内。

Supabase Pro 给你 8GB 数据库 + 100GB 存储 + 5万月活用户的 Auth,性价比很高。Vercel Postgres 虽然贵一点,但如果你整个应用栈都在 Vercel 上,省下的运维时间值这个差价。

MongoDB Atlas 按量计费,小规模的话一个月可能就几美元,也是个选择。但要盯着带宽费用,别让它失控。

中等预算阶段(月预算 $50-200)

这时候 PlanetScale($34/月起)、Supabase Team($599/年,约$50/月) 都可以考虑了。

选择标准:看性能需求。如果 QPS 需求不高,Supabase Team 版更划算,团队协作功能也更全。如果是高并发场景,PlanetScale 的性能优势值得投资。

大规模 / 高并发阶段

老实讲,到了这个阶段,云服务的性价比开始下降。很多公司会选择自建数据库,用 AWS RDS、Google Cloud SQL 或者自己搭 PostgreSQL 集群。

但如果团队规模小、没有专职 DBA,继续用 PlanetScale 或 Supabase 企业版也是合理的。把运维成本外包出去,专心做产品。

问题3：你的技术债承受能力？

最后一个问题,往往被忽略,但很关键。

能接受后期迁移的风险

那就先用免费的,快速验证产品。等确定项目有前景了,再考虑迁移或升级。

很多成功的产品都是这么走过来的。一开始用 MongoDB Atlas 免费版,跑到几千用户;然后发现需要更复杂的查询逻辑,迁移到 PostgreSQL;再后来流量暴涨,自建数据库集群。

关键是要做好准备:

1. 用 ORM 框架(Prisma、Drizzle)做抽象层,降低迁移成本
2. 数据库访问逻辑集中管理,别散落在各个文件里
3. 定期备份数据,迁移时有退路

希望一步到位,减少折腾

那就选成熟的、主流的方案: PostgreSQL + Supabase 或 PostgreSQL + 自建。

PostgreSQL 是目前最成熟的开源数据库,生态完善,迁移路径清晰。今天用 Supabase,明天可以无痛切换到 AWS RDS 或自建服务器,SQL 语句几乎不用改。

MongoDB 虽然灵活,但它的生态相对封闭。用了 MongoDB,将来要换成关系型数据库,基本等于重构。

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

我的个人经验

我现在新项目的默认选择是: Next.js + Prisma + Supabase。

原因很简单:

• Supabase 免费额度够用,有钱了再升级
• Prisma 的类型安全和迁移工具让我安心
• PostgreSQL 的生态意味着我随时可以跳槽到别的云服务
• 如果项目需要 Auth 或 Storage,Supabase 自带,省事

但如果项目是高并发场景,或者团队已经有成熟的数据库运维经验,我会直接上 PlanetScale 或自建方案。

实战配置清单

快速开始配置

理论讲够了,来点实际的。

这里给你几个常见组合的配置要点,不贴大段代码,但会告诉你关键的地方要注意什么。

方案1: Vercel Postgres + Prisma

最快5分钟能跑起来。

关键步骤:

1. 在 Vercel 项目里点 “Storage” → “Create Database” → 选 Postgres
2. 环境变量自动注入到 .env,直接用 process.env.POSTGRES_PRISMA_URL
3. 用 Prisma 生成客户端: npx prisma generate
4. 记得用 Prisma 的连接池配置,不然 Serverless 环境会爆连接数

注意点:

• 开发环境和生产环境的数据库要分开,别手滑把生产数据删了
• Prisma 的 migration 记得提交到 git,不然团队协作会乱套

方案2: Supabase + Prisma

功能最全,适合需要 Auth 的项目。

关键步骤:

1. Supabase 官网创建项目,拿到数据库连接字符串
2. 环境变量里配置 DATABASE_URL 和 DIRECT_URL(后者用于 migration)
3. 开启 Supabase 的 Pooler 模式,避免连接数问题
4. 如果需要 Auth,用 @supabase/auth-helpers-nextjs 库,和 Next.js 集成很顺滑

注意点:

• Row Level Security(RLS) 要配置好,不然数据安全会有问题
• Supabase 的 Realtime 功能默认没开,需要在表设置里手动启用

方案3: MongoDB Atlas + Mongoose

适合 JavaScript 背景的团队。

关键步骤:

1. MongoDB Atlas 创建集群,拿到连接字符串(记得把 <password> 替换成真实密码)
2. 用 Mongoose 定义 Schema,虽然 MongoDB 是 schemaless,但代码层面的类型约束还是要的
3. 连接时配置 serverSelectionTimeoutMS,避免冷启动超时
4. 查询时用 .lean() 返回纯 JavaScript 对象,性能更好

注意点:

• 千万别把数据库连接字符串(包含密码)提交到 git,用 .env.local 并加到 .gitignore
• MongoDB 的索引要手动创建,不然查询慢到你怀疑人生
• 聚合查询(Aggregation)的学习曲线有点陡,提前看文档

通用建议

不管用哪个方案,这几点都要做:

1. 环境变量管理: 用 .env.local(本地) 和 .env.production(生产),别混用
2. 连接池配置: Serverless 环境必须配,不然连接数会爆炸
3. 错误处理: 数据库查询一定要 try-catch,别让数据库错误直接暴露给用户
4. 备份策略: 定期备份,云服务也会出问题的
5. 监控告警: 配置好数据库性能监控,连接数、查询耗时这些指标要盯着

结论

说了这么多,回到开头那个问题:Next.js 项目到底该选什么数据库?

答案是:没有标准答案,但有决策框架。

问自己三个问题:

1. 项目类型: 个人项目?创业公司?企业应用?
2. 预算规模: 零预算?小预算(<$50)?中大预算?
3. 技术债承受力: 能接受后期迁移?还是希望一步到位?

如果你还是拿不准,我给个保守建议: Supabase + Prisma + PostgreSQL。

理由:

• 免费额度够个人项目用到有收入
• 功能全面(Database + Auth + Storage),省开发时间
• PostgreSQL 生态成熟,迁移路径多
• Prisma 的类型安全让代码更可靠

当然,如果你的项目有特殊需求——比如极致性能(PlanetScale)、灵活 schema(MongoDB Atlas)、深度 Vercel 集成(Vercel Postgres)——那就按需求选。

最后一句话:数据库选型不是一次性决定,是一个演进过程。先快速上线验证产品,再根据实际情况优化。别因为纠结技术方案,耽误了产品上线。

现在就打开你的项目,问自己这三个问题,10分钟做出决定,然后开始写代码。

如果遇到问题,评论区见。

22 分钟阅读 · 发布于: 2026年1月5日 · 修改于: 2026年1月22日

Easton

技术开发