Next.js 14 的 App Router 把服务端渲染推到了极致，但数据库选型却成了新的头疼事。
传统 RDS 实例连接池不够用、冷启动慢、按小时计费浪费钱。Serverless 数据库承诺按需付费、无限扩展、边缘计算优化，但产品太多，功能重叠又各有特色。Supabase 说自己是”开源 Firebase”，Neon 说自己”分离存储计算”，PlanetScale 说自己”MySQL 但不需要 migration”，Turso 说自己”SQLite 但能分布式”。
这篇文章实测 5 个主流方案，从冷启动延迟、边缘部署兼容性、定价透明度到生态成熟度，看看哪个最适合 Next.js 项目。
1. Supabase：BaaS 全家桶，不只是数据库
Supabase 不是单纯的数据库，而是一个完整的后端服务（Backend-as-a-Service）。它给你 Postgres + 认证 + 存储 + 实时订阅 + Edge Functions，一站式解决 Next.js 项目的后端需求。
核心优势：
- Postgres 全功能：RLS（行级安全）、PostGIS（地理数据）、全文搜索、JSON 支持，企业级特性都在
- 认证开箱即用：邮箱、OAuth（Google/GitHub）、Magic Link，不用自己写登录逻辑
- 实时订阅：数据库变更自动推送到前端，适合协作工具和实时 Dashboard
- 边缘 Functions：Deno Runtime，部署在 Cloudflare Workers 上，冷启动 < 50ms
适合场景：全栈 Next.js 项目，尤其是需要实时功能的。比如一个团队协作 SaaS，用户 A 修改数据后，用户 B 的界面要立刻同步——Supabase 的 Realtime 直接解决，不用自己搞 WebSocket。
另一个场景：indie hacker 的 MVP。注册登录 + 数据库 + 文件上传，Supabase 免费层全包了。一个人能在一周内搭起完整后端，专心写前端逻辑。
定价：
- Free：500MB 数据库 + 1GB 文件存储 + 50,000 月活用户
- Pro：$25/月，8GB 数据库 + 100GB 存储
- Team/Enterprise：按需定制
坦白讲，Supabase 的免费层在同类产品里最慷慨。50,000 MAU 够大部分 side project 用很久。但超出后价格跳到 $25/月，对于只需要数据库的项目有点贵——因为你为认证、存储、Functions 的基础设施买了单，即使不用。
注意事项：Supabase 的 Postgres 实例不是”真 serverless”，是托管实例按需休眠。免费层项目 7 天无活动会暂停，第一次访问需要唤醒（约 5-10 秒）。数据导出简单（Postgres dump），但认证用户、存储文件的迁移需要手动处理。
2. Neon：分离架构的 Serverless Postgres
Neon 只专注一件事：把 Postgres 做成真正的 serverless。它的架构是存储和计算分离——数据存在 S3，计算层按需启动和扩展。这带来两个核心优势：按实际使用量计费，以及极快的分支创建（类似 Git branch）。
核心优势：
- 真 serverless 架构：计算层自动休眠，0 活动时成本为 0。冷启动延迟约 500ms-1s。
- 数据库分支：每个 PR 可以创建独立的数据库分支，preview 环境和 production 数据隔离
- 无连接池限制：传统 Postgres 最多几百个连接，Neon 通过连接池层可以扛几万个并发
- Time Travel：免费保留 7 天历史数据，付费版 30 天，可以随时回滚到过去某个时间点
适合场景：Next.js 项目跑在 Vercel 上，需要给每个 preview deployment 单独的数据库。Neon 的分支功能完美契合 Vercel 的 PR 预览工作流——每次 push 自动创建数据库分支，merge 后自动删除，开发体验丝滑。
另一个场景：流量波动大的项目。比如新闻网站，平时 100 QPS，热点事件来了突然 10,000 QPS。Neon 的计算层自动扩展，过了高峰自动缩回，只按实际用量付费。
定价：
- Free：0.5GB 存储 + 191 小时计算时间/月（约每天 6 小时）
- Launch：$19/月，10GB 存储 + 300 小时计算
- Scale：$69/月起，按用量阶梯付费
Neon 的计费模型比 Supabase 透明。如果项目只在工作时间有流量，晚上和周末自动休眠，月费可以控制得很低。但如果是 24/7 高流量项目，计算时间费用会快速累加。
注意事项：冷启动延迟（500ms-1s）比 Supabase 慢，不适合对首次响应时间要求极高的场景。只有 Postgres，没有认证、存储等附加功能。如果需要这些，得自己集成或用其他服务。
3. PlanetScale：MySQL 但不需要 migration
PlanetScale 基于 Vitess（YouTube 用来扛 10 亿用户的 MySQL 分片方案），提供”无 downtime schema 变更”和”分支开发”能力。它的哲学是：数据库 schema 变更应该像代码部署一样安全和可预测。
核心优势：
- Non-blocking schema changes：改表结构不锁表，生产环境零停机
- 分支和 Deploy Request：在分支上改 schema，测试通过后合并到 main，类似 Git workflow
- 自动分片：数据量增长到单机瓶颈时，PlanetScale 自动水平分片，应用层无感知
- 连接池内置：不需要自己搞 PgBouncer 或 connection pooling
适合场景：团队协作的中大型 Next.js 项目，schema 变更频繁。传统 MySQL migration 要停机、回滚风险高，PlanetScale 的 Deploy Request 把 schema 变更变成可 review、可回滚的流程。
另一个场景：从小项目长成大项目的路径。一开始单表几万条数据，后来用户增长到几百万——PlanetScale 自动分片，不需要重写代码。
定价：
- Hobby：5GB 存储 + 10 亿行读/月 + 1000 万行写/月，免费（2024 年恢复免费层）
- Scaler：$39/月起，按读写行数计费
- Enterprise：定制合同
PlanetScale 在 2023 年取消免费层后被骂惨，2024 年又恢复了。但免费层限制比 Neon 和 Supabase 紧（只有 1 个生产分支，不能用 Deploy Request）。对于需要分支功能的团队，至少要 Scaler 计划。
注意事项：MySQL 不是 Postgres。没有 JSON 字段高级查询、没有 RLS、没有 PostGIS。如果项目依赖 Postgres 特性，PlanetScale 不合适。2026 年 4 月宣布不再支持外键约束（foreign keys），引发社区争议。理由是分片架构下外键难以维护，但这对依赖关系完整性的项目是个坑。
4. Turso：边缘计算的 SQLite
Turso 是最另类的选择——它不是 Postgres 也不是 MySQL，而是 libSQL（SQLite 的 fork）。核心卖点是”SQLite 但能分布式”，数据库实例部署在全球边缘节点上，查询延迟 < 10ms。
核心优势：
- 极低延迟：数据库副本部署在离用户最近的边缘节点，查询不需要跨洲
- 嵌入式兼容：本地开发时直接用 SQLite 文件，部署到 Turso 时数据自动同步
- 按数据库实例数计费：不是按存储或流量，而是按你创建了多少个数据库
- 多租户友好：每个租户一个独立数据库实例，天然隔离
适合场景：全球化的 Next.js SaaS，用户分布在不同大洲。比如一个协作工具，美国用户访问美国节点的数据库副本，欧洲用户访问欧洲节点——查询延迟从 200ms 降到 5ms，用户体验质变。
另一个场景：多租户 B2B SaaS。每个企业客户一个独立数据库实例（database-per-tenant 架构），数据隔离彻底，合规风险低。
定价：
- Starter：8GB 存储 + 1 个位置（location）+ 500 数据库，免费
- Scaler：$29/月，额外位置 $10/个/月
- Enterprise：定制
Turso 的定价模型适合多租户场景。如果你的 SaaS 有 500 个企业客户，每个客户一个数据库，Turso 免费层就够用。同等场景在 Supabase 或 Neon 上，要为每个租户的数据量单独计费。
注意事项：SQLite 的生态比 Postgres/MySQL 小。没有 PostGIS、没有全文搜索（需要自己集成）、ORM 支持有限。写入会复制到所有边缘节点，跨区域写入延迟比单区域高。适合读多写少的场景。
5. Firebase（Firestore）：NoSQL 但生态成熟
Firebase 是 Google 的 BaaS 平台，Firestore 是它的 NoSQL 数据库。虽然不是 SQL 数据库，但因为和 Next.js 的集成成熟、生态丰富，仍然值得考虑。
核心优势：
- 实时同步：数据变更自动推送到所有客户端，适合聊天、协作工具
- 离线支持：本地缓存 + 自动同步，弱网环境下体验好
- 认证 + 数据库 + 存储 + Analytics 一站式：比 Supabase 还全面的生态
- 免费层宽松：1GB 存储 + 50K 读/天 + 20K 写/天
适合场景：移动端为主、需要离线支持的项目。比如一个 Next.js + React Native 的跨端应用，用户在地铁里操作，出站后自动同步——Firestore 的离线模式天然支持。
另一个场景：原型验证（MVP）阶段。Firestore 的灵活 schema 让你快速迭代数据结构，不需要写 migration。等产品验证通过、数据模型稳定后，再考虑是否迁移到 SQL。
定价：
- Spark（免费）：1GB 存储 + 50K 读/天 + 20K 写/天
- Blaze（按量）：$0.18/GB 存储/月 + $0.06/10 万次读 + $0.18/10 万次写
Firestore 的读写计费要小心。如果查询没优化好，扫描了大量文档，费用会飙升。建议开启预算告警。
注意事项：NoSQL 意味着没有 JOIN、没有事务（跨文档）、没有复杂查询。如果业务逻辑依赖关系型数据，Firestore 会很痛苦。供应商锁定严重。Firestore 的数据格式、查询 API 都是 Google 私有的，迁移到其他数据库需要重写大量代码。
对比表格
| 数据库 | 类型 | 冷启动延迟 | 边缘部署 | 免费层 | 适合场景 |
|---|---|---|---|---|---|
| Supabase | Postgres (BaaS) | 5-10s（唤醒） | ❌ | 500MB + 50K MAU | 全栈 Next.js，需要认证 + 实时 |
| Neon | Postgres (Serverless) | 500ms-1s | ✅（读副本） | 0.5GB + 191h/月 | Vercel 部署，流量波动大 |
| PlanetScale | MySQL (Serverless) | < 1s | ❌ | 5GB + 有限分支 | Schema 变更频繁，团队协作 |
| Turso | SQLite (Edge) | < 100ms | ✅（全球） | 8GB + 500 数据库 | 全球用户，多租户隔离 |
| Firestore | NoSQL (BaaS) | < 100ms | ✅ | 1GB + 50K 读/天 | 移动端 + 离线支持 |
选型建议
全栈 Next.js，一个人开发：Supabase。认证、数据库、存储全包，不用集成多个服务。免费层够用很久。
部署在 Vercel，需要 preview 环境：Neon。数据库分支功能和 Vercel 的 PR 预览完美契合，开发体验最好。
团队协作，schema 变更多：PlanetScale。Deploy Request 把数据库变更变成可 review 的流程，避免生产事故。
全球化产品，用户分布各大洲：Turso。边缘节点部署让查询延迟降到 10ms 以内，体验提升明显。
MVP 快速验证，数据结构还不确定：Firestore。NoSQL 的灵活性让你快速迭代，等模型稳定再考虑迁移。
已有 Postgres 技能，不想学新东西：Neon 或 Supabase。两者都是标准 Postgres，现有知识直接复用。
常见误区
误区 1：”Serverless 数据库一定比传统 RDS 便宜”
不一定。如果项目 24/7 高流量，Neon 的计算时间费用可能超过 RDS 实例。Serverless 的优势在流量波动大或低流量场景。
误区 2：”边缘数据库延迟一定低”
只对读操作成立。写操作需要跨区域复制，延迟反而可能更高。Turso 适合读多写少，不适合高频写入。
误区 3：”免费层够用就一直免费”
免费层通常有隐藏限制：Supabase 7 天不活动会暂停、PlanetScale 免费层不能用分支、Neon 每月只有 191 小时计算时间。要算清楚实际成本。
总结
Next.js 的数据库选型没有银弹。Supabase 适合全栈快速开发，Neon 适合 Vercel 生态，PlanetScale 适合团队协作，Turso 适合全球化，Firestore 适合原型验证。
选择的核心是：你的项目是什么阶段？一个人 MVP、5 人团队、还是 50 人公司？用户在哪里？流量模式是什么？搞清楚这些，选择自然就出来了。
最后一个建议：别过度优化。早期项目选 Supabase 或 Neon，等用户增长到瓶颈再优化。数据库迁移成本没你想的那么高，但过早优化浪费的时间是真实的。
Stay updated with our latest AI insights
