在 2024 年底，我正在为金丝雀码头的一个金融科技客户做 SaaS 项目，已经三周了。该应用是一个 Next.js 14 仪表板，为小企业主拉取财务摘要。我默认选择了 Vercel Postgres，因为它就在 Vercel 仪表板中，我当时在快速迭代。六周后，我正在手动连接行级别的认证逻辑——这是 Supabase 在第一天就会免费给我的。这让我们多花了大约两个冲刺周期。不理想。
所以我想直言不讳地说：Supabase 和 Vercel Postgres 不是为同一个工作而竞争的等效工具。一个是完整的后端平台。另一个是一个托管的 Postgres 实例，带有一个很好的开发者体验包装器。选择错误的不会破坏你的应用，但它会悄悄地消耗你在其上花费的每一个小时。
这是我从在 Seahawk Media 的客户项目中交付两者所实际学到的。Seahawk Media.
---
它们实际上是什么（不是市场营销版本）
Vercel Postgres
Vercel Postgres 在 2023 年推出，基于无服务器 Postgres 公司 Neon 构建。这很重要，但经常被忽略。你基本上是在用 Neon 数据库，只不过上面套了一层 Vercel 风格的 SDK，账单也并入了你的 Vercel 计划。Neon, the serverless Postgres company. That's important and often glossed over. You're basically getting a Neon database with a Vercel-flavoured SDK on top and billing rolled into your Vercel plan.
你能得到的：一个 PostgreSQL 数据库、通过 @vercel/postgres 的边缘兼容连接池，以及与 Vercel 环境变量系统的紧密集成。你可以写 SQL 或在它之上使用 Drizzle/Prisma。基本就是这些。@vercel/postgres, and tight integration with Vercel's environment variable system. You write SQL or use Drizzle/Prisma on top of it. That's more or less it.
Supabase
Supabase 是完全不同的东西。底层是 Postgres，没错，但它被包裹在一个平台里，这个平台提供身份验证（通过 GoTrue）、实时订阅（通过 Phoenix channels）、文件存储、边缘函数，以及一个基于 PostgREST 的自动生成 REST API。Supabase 架构文档值得一读，如果你想理解各个部分如何配合的话。你选择的不只是一个数据库，而是一个有主张的后端栈。Supabase architecture docs are worth reading if you want to understand how the pieces fit. You're choosing an opinionated backend stack, not just a database.
这个区别在项目范围界定时立刻就显现出来了。用 Vercel Postgres，你仍需自己构建所有的身份验证、存储和 API 层。用 Supabase，这些工作中很大一部分已经做好了。
---
开发者体验：第一天 vs 第三个月
用 Vercel Postgres 的第一天确实很快。你在仪表板中点击"Create Database"，复制环境变量，安装 @vercel/postgres，然后在大约八分钟内写出你的第一个查询。我曾经计时过。如果你已经在 Vercel 生态中生活，这完全没有摩擦。@vercel/postgres, and write your first query in about eight minutes. I timed it once. It's frictionless if you already live in the Vercel ecosystem.
用 Supabase 的第一天也很快，但需要理解的东西多了点。仪表板很密集。表编辑器、身份验证设置、RLS 策略、存储桶、边缘函数，当你只是想存储三个用户数据表时，感觉会有点多。
但问题在这里。到第三个月，情况就反转了。用 Vercel Postgres，我一直在寻找第三方包来填补空缺：用 Clerk 或 NextAuth 做身份认证，用 Uploadthing 或 S3 做文件存储，用 Pusher 做实时功能。每一个集成都增加一个依赖、一条新的账单、一个新的故障点。而 Supabase，这些功能已经内置了，它们之间还能原生协作。
去年我在 Seahawk 做过一个项目，是一个健身品牌的社区平台，我们之所以选择 Supabase，是因为我们需要实时排行榜更新和用户生成的内容上传。我们在两周内交付了这些功能。我敢说，同一个项目如果用 Vercel Postgres 至少需要四周，因为我们得从零开始拼接 Pusher、S3 和 Clerk。
---
性能与扩展
两者都运行 Postgres。所以对于典型的网络应用负载，原始查询性能不会是你的差异化因素。两者都支持连接池。如果你的索引配置得当，两者都能轻松处理数百万行数据。
真正的性能故事在于架构。
Vercel Postgres 在底层使用 Neon，采用无服务器原生方式，计算和存储是分离的。冷启动是真实存在的。在免费和爱好者层级上，如果你的数据库有一段时间没被触及，新连接的第一个查询可能需要 500ms 或更长时间。对于流量可预测的仪表板应用，这只是个脚注。但对于用户不稳定的消费级应用，这就成了一个明显的问题。
Supabase 运行在专用实例上（或在付费计划上通过 PgBouncer 使用连接池）。它不会以同样的方式经历冷启动。Supabase 的连接池指南清楚地说明了 PgBouncer 如何根据计划配置。在免费层你能获得 60 个数据库连接。在 Pro 层你能获得 200 个。如果你的应用规模超过这个限制，你可以考虑 Supavisor（他们较新的连接器）或像 PgBouncer 事务模式这样的外部工具。Supabase connection pooling guide is clear on how PgBouncer is configured per plan. On the free tier you get 60 database connections. On Pro you get 200. Scale your app past that and you're looking at Supavisor (their newer pooler) or an external tool like PgBouncer in transaction mode.
在月活跃用户少于 10,000 的情况下，这两个平台都不会成为典型 SaaS 应用的瓶颈。超过这个数字后，讨论就会改变，你应该自己进行负载测试。
---
定价：这才是有意思的地方
这是我看到人们容易踩坑的地方。
Vercel Postgres 定价（截至 2025-2026）：
- Vercel Pro 中包含，$20/月（有限制）
- Pro 上 256MB 存储，之后 $0.30/GB
- 计算费用按使用量扩展
Supabase 定价：
- 免费层：500MB 数据库、1GB 文件存储、5 万月活跃用户（用于身份验证）
- Pro：$25/月，8GB 数据库，100GB 文件存储，10 万月活跃用户
如果你已经为 Vercel Pro 付费，数据库感觉像是"免费的"，因为它是捆绑的。这在心理上很有吸引力。但是一旦你加上 Clerk（$25/月）、Uploadthing 和 Pusher，你那个"免费"数据库实际上每月要花费你 $80 以上的相关工具成本。
Supabase Pro 每月 $25，可以替代上述大多数服务。对于中等规模的项目，Supabase 的总月费用通常更低，尽管数据库单项看起来成本更高。
一个诚实的免责声明：如果你是一个独立开发者，只在运行纯无服务器 API 路由、没有身份验证复杂度也没有实时需求，Vercel Postgres 确实更便宜也更简单。不要为你不会用到的功能付费。
---
Next.js 集成：实用部分
两个数据库都能很好地与 Next.js App Router 和 Server Actions 配合。但集成的体验不同。
使用 Vercel Postgres 的模式通常是：
- 写一个 Server Action 或 Route Handler
- 从 @vercel/postgres 导入 sql
sqlfrom@vercel/postgres - 运行你的查询
- 将数据返回给你的组件
简洁。熟悉。与 Drizzle ORM 完美配合，我已经使用 Drizzle 作为我的默认 ORM 大约 18 个月了，它与 Vercel Postgres 配合使用毫无问题。
使用 Supabase 时，Next.js 中的典型模式是：
- 创建 Supabase 客户端（通过 @supabase/ssr 在服务器端）
@supabase/ssr) - 使用客户端查询，或调用自动生成的 REST API
- 可选择使用 RLS 让数据库直接处理授权
@supabase/ssr 包在 2023 年首次推出时确实存在一些问题。现在好多了。过去在 Next.js 中间件中设置认证 cookie 流需要自定义实现；当前的文档处理得很干净。不过，这仍然比 Vercel Postgres 需要更多设置。一开始就要做好这个心理准备。@supabase/ssr package had some rough edges when it first launched in 2023. It's significantly better now. Setting up the auth cookie flow with Next.js middleware used to require a custom implementation; the current docs handle it cleanly. Still, it's more setup than Vercel Postgres. Accept that going in.
我真正喜欢 Supabase 在 Next.js 中的一点是：行级安全（Row Level Security）意味着我可以在 Server Action 中编写数据库查询，而不用担心不小心暴露其他用户的数据。授权逻辑存在于数据库中，而不是分散在我的应用代码各处。这在任何多租户应用中都是一个真正的架构优势。
---
何时选择 Vercel Postgres
- 你正在构建一个简单的内容网站、博客或没有认证需求的内部工具（或者你很乐意单独处理认证）
- 你已经深入 Vercel 生态系统，捆绑定价对你来说很划算
- 你的团队熟悉 SQL，想写原生查询或使用 Drizzle，不想要任何抽象层的开销
- 你在快速原型设计，知道会在 90 天内重新评估基础设施
---
何时选择 Supabase
用这个作为检查清单。如果你勾选了三个或以上，就选择 Supabase：
- 你需要用户认证（邮箱/密码、社交 OAuth、魔法链接）
- 你在构建实时功能：实时动态、协作编辑、在线状态指示器
- 你想要文件存储，但不想配置 S3 策略
- 你在构建多租户 SaaS，行级数据隔离很重要
- 你期望快速交付，并希望后端问题已经解决
- 你的项目有一位非技术类的利益相关者，他们需要用仪表板检查数据
我在 2025 年的一个房产列表平台上使用了 Supabase。客户需要代理商上传图片、买家实时保存收藏夹，以及一个具有基本报告功能的管理面板。身份验证、存储、实时功能、RLS，全部都包括了。我们直接使用 Supabase 内置的表编辑器让客户管理列表。完全不需要自定义管理面板。仅这一点就为我们节省了一周的时间。
---
供应商锁定的问题
值得指出。两个选项都会把你绑定到特定的基础设施上，只是方式不同。
使用 Vercel Postgres（Neon），你的数据存储在 Neon 数据库中。Neon 的开放程度相当高，迁移到自托管的 Postgres 实例是可行的。用 pg_dump，指向你的新主机，完成。锁定的真正问题是 Vercel 的开发体验层，而不是数据本身。pg_dump, point it at your new host, done. The lock-in is really Vercel's DX layer, not the data itself.
使用 Supabase，数据库锁定类似（毕竟是 Postgres），但平台锁定要更明显。你的身份验证是 GoTrue。存储是 Supabase Storage。实时功能是 Phoenix 通道设置。把所有这些迁移到不同的技术栈需要一周多的时间。这是一个真实的权衡，值得承认。Supabase 通过 Docker 提供自托管选项，见 Supabase 自托管指南，这在一定程度上缓解了供应商的顾虑。Supabase self-hosting guide, which mitigates the vendor concern somewhat.
两者都不会造成灾难性的锁定。但如果你正在构建三年后完全需要自己拥有的东西，就要在讨论中考虑这一点。
---
常见问题
Supabase 就是换成 Postgres 的 Firebase 吗？
大体上是的，但这样说低估了 Postgres 的优势。Firebase 用的是 Firestore，一个有自己查询模型的文档数据库。Supabase 给你的是真正的关系型数据库，支持联接、事务、外键，以及一切让 Postgres 值得用的东西。拿 Firebase 做比较主要是因为两者都遵循"开箱即用"的理念。如果你懂 SQL，正在构建关系型数据模型，Supabase 的开发体验会比 Firebase 舒适得多。
能否在不用 Supabase 的身份验证系统的情况下使用它？
可以。你可以纯粹把 Supabase 当作一个托管的 Postgres 数据库来用，然后用 Clerk 或 NextAuth 接入自己的身份验证。有些团队就这么干。说实话，我会质疑这个决定，因为你在付费用这个平台却没有用上它最省时间的功能，不过如果你对身份验证提供商有很强的想法，这在架构上确实是个合理的选择。
Vercel Postgres 能和 Prisma 一起用吗？
可以。@vercel/postgres 包通过标准的 Prisma Postgres 连接器与 Prisma 兼容。你在环境变量里设置 DATABASE_URL，Prisma 不关心后面连的是什么。我在两个项目里用过 Prisma + Vercel Postgres。我现在更倾向于 Drizzle，因为它的类型安全性更好，也不需要单独的迁移服务器，但 Prisma 也能完美胜任。@vercel/postgres package works with Prisma via the standard Prisma Postgres connector. You set your DATABASE_URL in your env vars and Prisma doesn't care what's behind it. I've used Prisma with Vercel Postgres on two projects. Drizzle is my preference now for the type safety and lack of a separate migration server, but Prisma works perfectly fine.
对于预算紧张的独立开发者来说，哪个更好？
Supabase 免费层真的很慷慨：500MB 存储，包括身份验证，包括实时功能。对于一个副项目或初期产品来说，很难找到更好的选择。Vercel Postgres 免费层就比较有限，真正的价值只有在你已经用上 Vercel Pro 的时候才能体现。如果我明天要开始一个个人项目，我会毫不犹豫地选 Supabase。
那直接用 Neon 呢，不用 Vercel Postgres？
很好的问题。既然 Vercel Postgres 底层就是 Neon，你可以去掉中间商直接使用 Neon。你会获得更多的计划灵活性、分支功能（Neon 的数据库分支用于预览环境的功能确实很出色），而且不会被 Vercel 的定价方案束缚。如果你使用 Vercel Postgres 主要只是为了数据库功能，而不是为了生态系统集成，那真的应该考虑直接通过他们的官方 Next.js 集成来使用 Neon。official Next.js integration.
---
诚实的总结：Vercel Postgres 是一个很好的数据库，适合那些想要少做一个选择的 Vercel 原生项目。Supabase 是一个后端平台，恰好包含了一个很好的数据库。先明确你的项目范围，然后选择与你实际在构建的东西相匹配的工具。我曾经反向操作过，浪费了好几个冲刺周期。你可能不需要犯同样的错误。