Neon vs Turso vs PlanetScale：2026 年如何选择无服务器数据库
Engineering Team
简要回答
如果您需要 PostgreSQL 兼容性和现代开发体验，请选择 Neon。如果您需要在边缘实现低于 10ms 的读取延迟和 SQLite 兼容性，请选择 Turso。如果您运行 MySQL 工作负载并需要水平分片，请选择 PlanetScale。三者在 2026 年都已生产就绪，选择主要取决于您的 SQL 方言偏好和部署拓扑。
2026 年无服务器数据库格局
无服务器数据库市场自 2023 年以来已显著成熟。从实验性托管产品发展为初创公司的默认部署模型，也是企业越来越常见的选择。全球无服务器数据库市场在 2025 年达到 142 亿美元，年复合增长率 28%（据 Gartner）。
三个平台已成为明确的领导者，每个都建立在根本不同的基础上：
- Neon — 无服务器 PostgreSQL，具有存储计算分离、分支和缩放至零
- Turso — libSQL（SQLite 分支），具有边缘复制、嵌入式副本和按请求路由
- PlanetScale — MySQL 兼容，基于 Vitess（YouTube/Google 的扩展技术），具有安全的模式部署
三者不可互换。每个在不同的架构上下文中表现出色，选择错误会产生随时间累积的摩擦。
Neon：做对了的无服务器 PostgreSQL
Neon 是一个无服务器 PostgreSQL 平台，将存储与计算分离，实现传统 PostgreSQL 部署中不可能的功能：即时分支、缩放至零和存储层的时间点恢复。
架构
Neon 的架构将 PostgreSQL 分为三层：
- 计算层： 处理查询执行的标准 PostgreSQL 实例
- Pageserver： 替代 PostgreSQL 本地文件系统的自定义存储后端
- Safekeepers： 确保已提交事务不丢失的 WAL 持久性节点
这种分离意味着计算可以独立于存储进行扩展。Neon 数据库可以在空闲时缩放至零（仅支付存储费用），并在连接到达时约 500ms 内启动计算端点。
分支：杀手级功能
Neon 最独特的能力是数据库分支，以 Git 为模型。创建分支是一个写时复制操作，无论数据库大小如何都能在毫秒内完成。
# 从生产环境创建分支用于测试
neonctl branches create --name feature-auth-redesign --parent main
# 获取分支的连接字符串
neonctl connection-string feature-auth-redesign
分支的使用场景：
- 预览环境： 每个 Pull Request 获得自己的数据库分支和生产数据。
- 安全迁移： 从生产环境分支，在分支上运行迁移，验证后再应用到生产环境。
- 分析隔离： 为重型分析查询创建分支，不影响生产 OLTP 性能。
- 开发： 每个开发者获得个人数据库分支。
自动扩展
Neon 根据负载从 0.25 vCPU 自动扩展到 8 vCPU。缩放至零功能是真实的——如果 5 分钟内没有查询到达，计算完全关闭。
定价（2026 年 3 月）
| 计划 | 计算 | 存储 | 分支 | 价格 |
|---|---|---|---|---|
| 免费 | 0.25 vCPU，100 小时/月 | 512 MB | 10 个分支 | $0 |
| Launch | 最多 4 vCPU | 10 GB | 无限 | $19/月 |
| Scale | 最多 8 vCPU | 50 GB | 无限 | $69/月 |
| 企业 | 自定义 | 自定义 | 无限 | 自定义 |
局限性
- 冷启动延迟。 缩放至零端点需要 300-700ms 恢复。
- 扩展支持。 大多数流行扩展可用（PostGIS、pgvector、pg_stat_statements），但一些需要文件系统访问的不支持。
- 区域可用性。 截至 2026 年 3 月，可在 12 个 AWS 区域和 5 个 Azure 区域使用。
Turso：边缘原生 SQLite
Turso 基于 libSQL 构建，这是 SQLite 的开源分支，添加了服务器功能：复制、访问控制和多租户。Turso 的独特价值主张是边缘原生部署——您的数据库在全球 30+ 个位置运行。
架构
- 主实例： 在您选择的主区域中的单写入器 libSQL 数据库
- 边缘副本： 部署到全球边缘位置的只读副本
- 嵌入式副本： libSQL 可以直接在应用进程中嵌入只读副本
import { createClient } from '@libsql/client';
const db = createClient({
url: 'file:local-replica.db',
syncUrl: 'libsql://my-db-username.turso.io',
authToken: process.env.TURSO_AUTH_TOKEN,
syncInterval: 60,
});
// 此读取命中本地文件——亚毫秒级
const users = await db.execute('SELECT * FROM users WHERE active = 1');
多租户
Turso 支持每个账户创建数千个数据库，每个都是独立的 SQLite 文件。
定价（2026 年 3 月）
| 计划 | 数据库 | 存储 | 读取行/月 | 写入行/月 | 价格 |
|---|---|---|---|---|---|
| Starter | 500 | 9 GB | 250 亿 | 5000 万 | $0 |
| Scaler | 10,000 | 24 GB | 1000 亿 | 1 亿 | $29/月 |
| 企业 | 无限 | 自定义 | 自定义 | 自定义 | 自定义 |
最适合
- 边缘应用： 部署在 Cloudflare Workers、Vercel Edge Functions 或 Deno Deploy 上的应用
- 每租户数据库： 需要数据隔离的 SaaS 应用
- 移动/离线优先应用： 嵌入式副本支持离线读取和后台同步
- 读取密集型工作负载： 嵌入式副本模型提供亚毫秒级读取延迟
PlanetScale：YouTube 规模的 MySQL
PlanetScale 将 Vitess——驱动 YouTube、Slack 和 GitHub 的分片中间件——作为托管服务提供给开发者。
架构
- VTGate： MySQL 兼容代理，将查询路由到正确的分片
- VTTablet： 管理各个 MySQL 实例（分片）
- VTOrc： 自动故障转移和拓扑管理
安全模式更改
# 创建分支
pscale branch create feature-add-orders
# 将模式更改应用到分支
pscale shell feature-add-orders
mysql> ALTER TABLE orders ADD COLUMN status ENUM('pending', 'shipped', 'delivered');
# 创建部署请求
pscale deploy-request create feature-add-orders
# 部署到生产环境（非阻塞，在线 DDL）
pscale deploy-request deploy feature-add-orders 1
定价（2026 年 3 月）
| 计划 | 存储 | 读取行/月 | 写入行/月 | 连接 | 价格 |
|---|---|---|---|---|---|
| Hobby | 5 GB | 10 亿 | 1000 万 | 1,000 | $0 |
| Scaler | 10 GB | 1000 亿 | 5000 万 | 10,000 | $29/月 |
| Scaler Pro | 128 GB | 无限 | 2 亿 | 20,000 | $99/月 |
功能对比表
| 功能 | Neon | Turso | PlanetScale |
|---|---|---|---|
| SQL 方言 | PostgreSQL | SQLite (libSQL) | MySQL |
| 缩放至零 | 是（300-700ms 恢复） | 是（即时） | 否（始终运行） |
| 分支 | 完整数据分支 | 模式 + 数据 | 仅模式部署请求 |
| 边缘副本 | 否 | 是（30+ 位置） | 否 |
| 嵌入式副本 | 否 | 是（零延迟读取） | 否 |
| 水平分片 | 否 | 否 | 是（Vitess） |
| 在线 DDL | 标准 PG（带锁） | 短暂锁 | gh-ost（零锁） |
| 向量搜索 | pgvector | 通过扩展 | 无原生支持 |
| 免费层 | 512 MB，100 计算小时 | 9 GB，500 数据库 | 5 GB，10 亿读取 |
决策框架
选择 Neon 当：
- 需要 PostgreSQL 兼容性（扩展、JSONB、PostGIS、pgvector）
- 数据库分支对工作流程很重要
- 需要开发和暂存环境的缩放至零
选择 Turso 当：
- 部署在边缘运行时（Cloudflare Workers、Deno Deploy、Vercel Edge）
- 亚毫秒级读取延迟是要求（嵌入式副本）
- 需要多租户 SaaS 的每租户数据库隔离
选择 PlanetScale 当：
- 团队是 MySQL 原生的，不想切换 SQL 方言
- 需要水平分片处理数十亿行的表
- 零停机模式迁移至关重要（在线 DDL）
常见问题
可以在这些平台之间迁移吗？
可以，但不简单。Neon 到 PlanetScale 或反过来需要 SQL 方言迁移。生产应用程序预计需要 2-4 周的迁移工作。
哪个对小项目最便宜？
三者都有慷慨的免费层。Turso 的免费层最慷慨（9 GB 存储，500 数据库）。对于业余项目，三者实际上都是免费的。
有替代 Redis 做缓存的吗？
Turso 的嵌入式副本可以替代 Redis 的读缓存场景。
与 Supabase 相比如何？
Supabase 是基于 PostgreSQL 的更广泛平台（认证、存储、实时、边缘函数）。Neon 是专注的无服务器 PostgreSQL 产品。
哪个处理最多并发连接？
PlanetScale，得益于 Vitess 的连接多路复用。可以处理 100,000+ 应用连接。