Neon vs Supabase vs PlanetScale: Serverless Postgres SaaS 对比决策矩阵

本文由 Huifer 撰写，TanStack Ship 独立开发者与维护者。 我在 Cloudflare Workers 上运行着 7 款 SaaS 应用，其中 4 款使用 Neon、2 款使用 Supabase、1 款使用 PlanetScale。在做这次对比之前，我还有 2 款应用在 Supabase、1 款在 PlanetScale，后来都已完成迁移。本文是我在 2026 年 3 月至 4 月运行的 30 天测试记录，目的是为 TanStack Ship 选定默认数据库，并如实说明每款数据库的优势所在。没有供应商赞助本文；所有数据库费用都是我自掏腰包。声明：这是一篇独立对比，不含任何联盟链接，也不与文中提及的任何供应商存在实质性关联。

信息来源：Neon 定价 · Neon 分支文档 · Supabase 定价 · Supabase Auth 文档 · PlanetScale 定价 · PlanetScale Boost 文档 · Drizzle ORM 文档 · TanStack Start Server Functions · TanStack Ship GitHub · Postgres 官方文档 最后更新：2026-05-11 · 更新日志

TL;DR： 对于 Cloudflare Workers 上的独立 SaaS，Neon 在冷启动、分支功能和成本方面胜出，适用于大多数场景。Supabase 在你需要 auth、storage 和 realtime 一站式管理时胜出，代价是接受捆绑定价。PlanetScale 在原始写入吞吐量和零停机 Schema 变更上胜出，但 2026 年的价格约为 Neon 的 2 倍，且仅支持 MySQL 这一约束不容忽视。TanStack Ship 默认采用 Cloudflare D1 处理热路径、Neon 处理冷路径——这一组合覆盖了 80% 的独立 SaaS 工作负载。

我的实际测试方法

任何对比在有价值之前，读者和我必须先就测试对象达成一致。"serverless Postgres" 这个标签被用得太随意了。

根据 Neon 文档，Neon 是存储与计算分离的 serverless Postgres，可以将计算规模缩容至零。根据 Supabase 文档，Supabase 是托管式 Postgres，捆绑了 auth、storage、realtime 和 edge functions。根据 PlanetScale 文档，PlanetScale 是一个基于 Vitess 构建的 MySQL 兼容数据库，具备分支和零停机 Schema 变更功能；它出现在相同的采购讨论中，但并非 Postgres。

忽略 MySQL/Postgres 之分的对比是误导性的——这个区分对 ORM 选择、功能对等和迁移成本都有实质影响。

测试设置

我对相同工作负载运行了为期 30 天的对等基准测试：12 张表的 Schema、70/25/5 的读/写/分析分割比例、us-east-1 数据库区域、Cloudflare Workers 边缘应用、Drizzle ORM（Neon 和 Supabase 用 Postgres 方言，PlanetScale 用 MySQL 方言），测试查询 SELECT id, email, created_at FROM users WHERE id = $1。

数据来自测试运行结果，而非供应商的基准数据。PlanetScale 和 Neon 的实际表现比其营销文案暗示的要好；Supabase 在冷启动方面比其营销口径略差。

背景可参考 Cloudflare D1 vs Postgres 生产实测 和 Cloudflare D1 vs Supabase 独立创始人 SaaS 选数据库。

冷启动：边缘应用最关键的性能指标

对于 Cloudflare Workers 应用，数据库冷启动是最大的性能杠杆。一次在边缘只需 5ms 的请求，如果要等待 800ms 的冷启动数据库，就是一次 800ms 的请求。

Neon 的 p99 480ms 意味着一个缩容至零的数据库被按需唤醒。Supabase 免费层 p99 1,200ms 是我在生产环境中真实遇到过的失败案例——空闲 5 分钟后第一个请求要支付全部冷启动代价。Supabase Pro p99 90ms 则是同一数据库开启始终在线计算的结果；你花更多钱来规避冷启动。

Neon 是这三者中唯一默认就把冷启动故事讲对的。 Supabase 只有在付费层才能与之匹敌；PlanetScale 有竞争力但并不更优。

这对你的应用意味着什么

如果你的 SaaS 流量稳定（ToB 仪表板、内部工具），冷启动几乎不会触发。如果你的 SaaS 流量有突发性（一个每天只用两次的消费级工具、一个 webhook 接收器），冷启动会不断触发，数据库选择就是 100ms 请求与 1,200ms 请求之间的差别。我在 InvoiceFlow 上学到了这一点——在我们上线 webhook 接收器之前，冷启动根本不是问题。

分支功能：改变我看法的工作流特性

对于独立开发者来说，数据库分支是过去五年最大的生产力释放。每一个 git 分支都对应一个独立的临时数据库。

根据 Neon 分支文档，Neon 将分支作为原生特性交付。每个分支是父分支的写时复制克隆，成本约 $0.10/天，一行 API 调用即可重置。GitHub Actions 集成只需一个配置文件。如果没有分支功能，我的 7 款应用测试需要 3 周，有分支只需 3 天。

Supabase 在 2025 年通过 Supabase CLI 添加了分支功能。工作流比 Neon 更重——项目启动需 30 秒，GitHub 集成需使用 Supabase 托管的 runner。

PlanetScale 为 MySQL 发明了数据库分支。根据 PlanetScale 文档，每个分支都是一个真实的 Vitess 分片，支持零停机 Schema 变更。限制是你必须使用 PlanetScale 的 deploy requests 来合并 Schema 变更，这是一种工作流层面的锁定。

对于想要 30 秒内创建分支、每分支成本仅几毛钱的独立 SaaS 开发者，Neon 胜出。对于有 DBA 且需要 deploy-request 审查的团队，PlanetScale 是黄金标准。Supabase 做得不错，但没有差异化优势。

10 GB 存储、50 GB 出口流量、1 亿行读取的定价

以下是 2026 年 5 月每款数据库的定价，对应"运行满一年的 SaaS 实际工作负载"：10 GB 存储、50 GB 出口流量、每月 1 亿次读取、500 万次写入。

Neon Launch 每月 $19 是 10 GB 以下独立 SaaS 的最低价。Supabase Pro 每月 $25 不含捆绑包时具有竞争力。PlanetScale Scaler Pro 每月 $39 约为 Neon 的 2 倍；Enterprise 每月 $399 意味着 PlanetScale 已不再是独立开发者的选项。

隐藏成本：捆绑定价

Supabase 招牌上的 $25/月仅限数据库本身。加上 Supabase Auth、Storage 和 Realtime，最低需支付 $99/月。相比 Clerk + Postgres + S3 的小型 SaaS 方案，这个价格有竞争力，但相对于 Neon + Better Auth + R2（同等技术栈约 $40–$50/月）就称不上"便宜"。Auth 相关内容可参考 Auth0 vs Clerk vs 自建：SaaS Auth 成本与控制权对比。

生产代码：TanStack Start 中的 Neon + Drizzle

TanStack Ship 启动模板预配置了 Drizzle ORM。以下是实际的 db.ts，略有删改：

// src/lib/db.ts — TanStack Ship 启动模板（Neon）
import { drizzle } from "drizzle-orm/neon-http";
import { neon } from "@neondatabase/serverless";
import * as schema from "./schema";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql, { schema });

export async function getUser(id: string) {
  const rows = await db
    .select()
    .from(schema.users)
    .where(eq(schema.users.id, id))
    .limit(1);
  return rows[0] ?? null;
}

对应的 schema 文件使用标准 Drizzle 表定义：

// src/lib/schema.ts
import { pgTable, uuid, text, timestamp, jsonb } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: uuid("id").primaryKey().defaultRandom(),
  email: text("email").notNull().unique(),
  name: text("name"),
  metadata: jsonb("metadata").$type<Record<string, unknown>>(),
  createdAt: timestamp("created_at").defaultNow().notNull(),
});

这是我四分之三生产应用实际运行的代码。Neon HTTP 驱动是边缘原生的——每次请求只需一轮往返到 Neon 的区域代理。完整接入方案见 TanStack Ship 启动模板 和 Drizzle ORM 文档。

各数据库真正胜出的场景

Neon 胜出的场景：Cloudflare Workers 上的独立开发者（冷启动默认正确、定价最低、分支仅需一个配置文件）；Postgres 且运维负担最小化（我使用 Neon 过程中无需处理连接池或 vacuum 调度）；突发流量工作负载（webhook 接收器、定时报表——缩容至零是真实的成本优势）。

Supabase 胜出的场景：需要 auth + storage + realtime 一站式管理（捆绑包节省一周开发时间）；Postgres 行级安全（RLS）作为主要授权层；第一天就需要管理后台（Supabase Studio 对非技术用户友好）。

PlanetScale 胜出的场景：写入密集型工作负载（Vitess 分片处理单 Postgres 节点无法承受的写入吞吐量）；大表零停机 Schema 变更（在线 DDL 通过 gh-ost 是同类最佳）；有 DBA 且需要 deploy-request 审查的团队。

PlanetScale 是 MySQL，不是 Postgres。如果你的 SaaS 使用 Postgres 特有功能（JSONB 操作符、部分索引、tsvector 全文搜索），迁移成本不容小觑。我在 2024 年的一个项目中学到了这点——我们估了两周，实际花了六周。

其他数据后端可参考 Cloudflare D1 vs Postgres 生产实测 和 用量计量：ClickHouse vs Postgres。

诚实的决策矩阵

对于 TanStack Ship 启动模板，默认组合是 Cloudflare D1 处理热路径（auth、sessions、计费）和 Neon 处理冷路径（分析、审计日志、大表关联）。这一组合覆盖了约 80% 的独立 SaaS 工作负载，在 1 万 MAU 时月账单控制在 $50 以下。详见 TanStack Ship 功能 和定价页面。

常见问题

Neon 对付费客户是否已生产就绪？ 是的——我在 Neon 上运行着四款生产 SaaS。需要注意的是 p99 480ms 的冷启动；如果你的用户对延迟敏感，保持 Launch 层并开启始终在线计算。

Supabase 免费层可以用于生产吗？ 用来做原型可以。用于付费客户——不行——p99 1,200ms 冷启动会直接出现在你的监控仪表板上。Pro 层（$25/月）是最低要求。

以后可以从 Supabase 迁移到 Neon 吗？ 可以。两者都是 Postgres；迁移流程是 pg_dump + pg_restore 加一次 IAM 切换。每次迁移我大约用了一天。

PlanetScale 支持类似 Neon 的 serverless 驱动吗？ 支持，通过 PlanetScale Boost。冷启动有竞争力；入门价（$39/月）高于 Neon Launch 的 $19/月。

TanStack Ship 能同时支持这三者吗？ 可以——Drizzle 支持 Postgres 和 MySQL。只需改连接字符串和方言导入；应用代码无需改动。启动模板默认使用 Neon，/examples 中提供了 Supabase 和 PlanetScale 的适配器。

Cloudflare D1 呢？ D1 在热路径上表现优秀，5 GB 以内免费。分析、审计日志和超过 10 GB 的工作负载建议用 Postgres。TanStack Ship 默认组合是 D1 + Neon。