本文由 Huifer 撰写，他是 TanStack Ship 的独立开发者与维护者。我在 8 个生产 SaaS 应用中运行 D1，在 2 个生产 B2B 应用中运行 Neon，还在较小的项目中交付过 Cloudflare Durable Objects、Turso/libSQL 和 Supabase。这篇文章就是我希望当初有人写给我的诚实对比——每个选项先说强项，再说它输在哪里，最后给出决策框架。没有厂商赞助；以下每个结论都来自生产环境追踪。

信息来源：Cloudflare D1 文档 · D1 最佳实践 · D1 限制 · Neon serverless Postgres · Supabase 文档 · Turso / libSQL · Cloudflare Durable Objects · SQLite 查询规划器 · Workers Analytics Engine · TanStack Ship 数据库指南

最后更新：2026-09-11 · Changelog

TL;DR： 对 2026 年的 Workers 原生、读多写少 SaaS 来说，D1 是正确的默认选择——区域副本带来亚毫秒读取、无需连接池、SQLite 查询规划器、一条账单。诚实的替代项是：Neon（需要 JSONB 和 LISTEN/NOTIFY 时的 serverless Postgres）、Supabase（Postgres + 认证 + 存储打包）、Turso/libSQL（D1 副本拓扑不合身时的多区域边缘方案），以及 Cloudflare Durable Objects（实时协调的按实体状态）。本文在每个选项最强的维度上比较它，指明它输在哪里，最后给出决策矩阵。想先看性能深挖，见 D1 性能基准文章；生产模式见 D1 生产指南。

Cloudflare D1 vs 替代方案：2026 年诚实对比

「2026 年 SaaS 最好的数据库是什么」没有唯一答案，但有几个诚实的答案。Cloudflare D1 是其中之一；Neon、Supabase、Turso 和 Cloudflare Durable Objects 是我交付过的其他几个。每个替代项都会在其最强的维度上被承认，然后指出它实际输在哪里，最后是决策矩阵。

2026 年的生产数据库决策

过去三年，三股力量重塑了独立 SaaS 开发者的数据库格局。边缘运行时——Cloudflare Workers、Vercel Edge、Deno Deploy——把计算推到离用户更近的地方。Serverless Postgres——Neon、Supabase、PlanetScale——用按量计价取代了「开一台每月 40 美元的 Postgres 虚拟机」的决策。SQLite 成了分布式系统原语，libSQL 和 D1 把单文件引擎变成全球复制的数据库。

对 SaaS 创始人来说，实际后果是：数据库选择不再是「哪个引擎最好」，而是「哪种取舍匹配你应用的形态」。

Cloudflare D1：边缘 SQLite 的押注

D1 的 schema 形态就是每个开发者都熟的 SQLite 方言——INTEGER PRIMARY KEY、TEXT、部分索引。数据库活在边缘，复制由平台代劳。

-- D1 schema: SQLite dialect, tenant_id first
CREATE TABLE projects (
  id           TEXT PRIMARY KEY,
  tenant_id    TEXT NOT NULL,
  name         TEXT NOT NULL,
  created_at   INTEGER NOT NULL DEFAULT (unixepoch())
);

CREATE INDEX idx_projects_tenant_created
  ON projects(tenant_id, created_at DESC);

强项：D1 赢在哪里

D1 的三个生产优势在我全部 8 次部署中都成立。

第一，区域读副本 + 零连接池。D1 自动在 Cloudflare 网络中创建读副本，我的追踪数据显示，从最近副本服务的主键读取在 1.5 毫秒内返回。根据 D1 文档，从请求的视角看绑定是无状态的——没有连接池要调优，没有最大连接数要担心。对独立开发者，这种运维简单性值真金白银。

第二，SQLite 的查询规划器。SQLite 是单文件引擎，规划器保守。根据 SQLite 查询规划器文档，规划器跨版本表现一致——这意味着开发环境的 EXPLAIN 输出就是生产环境的执行计划。这种确定性比「更聪明的规划器」更重要。

第三，Workers 原生集成。D1 是 env 里的一个绑定，不是连接字符串。没有驱动、没有 pg 客户端、没有 SSL 握手——Worker 启动时绑定就在那里。对 Cloudflare 原生的 SaaS，集成成本为零。

限制：D1 何时不再是正确选择

三个限制让我在生产环境付出过真实时间。

第一，数据库级写锁。每次变更都在单一写锁后串行化。上限会变，但形状一致：同一个数据库超过每秒几百次变更后急剧掉速。D1 写锁复盘记录了 250 req/s 的天花板。

第二，单库 10 GB 上限。根据 D1 限制文档，每个数据库上限 10 GB。对某个租户独占大头的多租户 SaaS，这是真实约束。解法是分片，但运维面积随之增长。

第三，SQLite 特有的功能缺口。所有 Postgres 特有的东西——JSONB 操作符、LISTEN/NOTIFY、咨询锁——都得用 SQLite 方言重新表达或者放弃。全文检索是人们以为会失去、而 D1 其实覆盖的那个 Postgres 功能：SQLite 的 FTS5 扩展在生产中表现良好，见 D1 FTS5 全文搜索指南。优化走查见 D1 优化详解。

基于 Postgres 的生产替代方案

Neon：serverless Postgres

对 SaaS 创始人来说，Neon 是精神上最接近 D1 的表亲，只是构建在 Postgres 而非 SQLite 上。根据 Neon 文档，Neon 把计算与存储分离：兼容 Postgres 的计算层从分布式存储层读取，冷计算约 500 毫秒启动。我运行的两个 Neon 部署是日请求约 5 万的 B2B 分析工具和一个开发者仪表盘。

-- Neon / Postgres: same shape, different dialect
CREATE TABLE projects (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id    UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  name         TEXT NOT NULL,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_tenant_created
  ON projects(tenant_id, created_at DESC);

-- Postgres-specific: JSONB indexing for tenant settings
ALTER TABLE tenants ADD COLUMN settings JSONB NOT NULL DEFAULT '{}';
CREATE INDEX idx_tenants_settings ON tenants USING GIN (settings);

JSONB 列和 GIN 索引正是 Neon 开箱即给、而 SQLite 确实没有的那类功能。

Neon 赢过 D1 的地方。 如果你的 SaaS 依赖 Postgres 特有功能——JSONB 索引、LISTEN/NOTIFY、pgvector——Neon 是正确选择。Postgres 方言是 SaaS 后端的通用语，几乎每个 SaaS 库都默认它。对要招工程师的 SaaS，「Postgres」是招聘故事；「边缘上的 SQLite」需要解释。

Neon 输给 D1 的地方。 实测中，从 Cloudflare Worker 到 Neon 的冷启动延迟约 50 毫秒 RTT——相对 D1 的亚毫秒副本读取是 30 倍的退化。对一次请求要做 5–10 次数据库调用的路径，这会累积。Neon 和所有 Postgres 一样有连接，从 Workers 使用的正确模式是拿 Hyperdrive 当连接池。

Supabase：Postgres + 认证 + 存储打包

Supabase 是另一种形态的替代项：不只是数据库，而是一个有主见的后端即服务。根据 Supabase 文档，它在同一个仪表盘和 SDK 后面提供数据用的 Postgres、认证用的 GoTrue、文件用的 Storage、计算用的 Edge Functions。对独立创始人，吸引力是真实的：无聊的那半截技术栈交给一家供应商。

Supabase 赢的地方。 认证和存储打包是差异化所在。带邮箱/密码、OAuth、magic link 和行级安全策略的托管认证——Supabase 给你。带图像变换的文件存储——Supabase 给你。用户、表、存储的单一仪表盘——Supabase 给你。对 MVP，这是最快的路径。

Supabase 输给 D1 的地方。 打包也是锁定：认证流程、RLS 策略、存储 URL 都是 Supabase 形状的；迁走是真实工作量。从 Cloudflare Worker 出发的冷启动延迟约 50 毫秒 RTT，因为 Supabase 跑的也是 Postgres。对每次请求 10+ 次数据库调用的应用，这会累积。

边缘上的 SQLite：Turso 与 libSQL

Turso：libSQL 的多区域边缘

在「边缘 SQLite」这个品类里，Turso 是 D1 最直接的竞品。根据 Turso / libSQL 文档，Turso 运行 libSQL——SQLite 的一个分支，带网络复制、内嵌副本，以及由你掌控的多区域拓扑。我交付的两个 Turso 项目都是较小的 SaaS，彼时我想要显式的按区域副本布置。

// Turso: libSQL embedded replica at the edge
import { createClient } from '@libsql/client'

const db = createClient({
  url: 'file:./local-replica.db',
  syncUrl: 'libsql://my-db.turso.io',
  authToken: process.env.TURSO_TOKEN,
})

// Reads served from the local embedded replica; syncs from primary
const projects = await db.execute('SELECT * FROM projects WHERE tenant_id = ?', [tenantId])

内嵌副本模式是 libSQL 独有的优势——把一个 SQLite 文件发到边缘、让它从主库同步，读取就是本地的，没有网络往返。

Turso 赢过 D1 的地方。 副本拓扑由你配置。如果用户集中在三个特定区域、你想保证副本就布置在那里，Turso 允许你钉死。libSQL 还支持内嵌副本——发到边缘、从主库同步的 SQLite 文件。对区域高度集中的场景，这是真优势。

D1 赢过 Turso 的地方。 D1 与 Cloudflare Workers 的集成更紧。没有要加的驱动、没有第二个供应商关系、没有第二条账单。D1 副本是自动的；Turso 需要你手动布置。在中等规模下 D1 也便宜得多——免费档就能撑起一个真实的 SaaS MVP。

NoSQL 与键值替代方案

Cloudflare Durable Objects

Durable Objects 不是与 D1 同形态的数据库，但对正确的 SaaS 模式，它就是正确的原语。根据 Cloudflare Durable Objects 文档，每个 Durable Object 是一个带强一致键值存储的单线程计算实例，按 ID 寻址，并保证同一时刻只运行在一个区域。

Durable Objects 赢的地方。 实时协调——聊天室、多人游戏——是教科书式用例。单线程保证意味着没有写锁：同一时刻只有一个请求在该对象上运行，而那是你自己的代码。对按实体的状态——一个预订、一条 websocket——Durable Objects 是正确原语。

D1 赢过 Durable Objects 的地方。 「给我这个租户的所有项目」这类跨多租户数据的多行查询，D1 才是正确原语。Durable Objects 不为跨对象查询设计；你需要在它旁边配一个 D1。正确的架构是：每个活跃会话一个 Durable Object，外加一个做跨实体查询的 D1 数据库。

Cloudflare KV

Cloudflare KV 是替代项里最简单的：全局键值存储，最终一致，单值上限 25 MB。它是功能开关、会话数据块和配置的正确原语，也是任何关系型负载的错误原语。

决策矩阵：什么场景用什么数据库

选择不是「哪个数据库最好」——而是「哪种取舍匹配你应用的形态」。下面是我给创始人做咨询时用的矩阵，也是驱动 TanStack Ship 数据库选择的矩阵。

对我 2026 年交付的大多数 SaaS 应用——读多写少的仪表盘、项目列表、设置、账单摘要、CRUD——D1 都是正确的默认。模式是：D1 管应用数据，Durable Objects 管按实体的实时状态，Cloudflare Queues 管能容忍几秒延迟的写入路径，KV 管功能开关和配置。这套栈现在是 TanStack Ship 的默认配置，模式记录在 D1 生产指南和 D1 深挖详解里。

诚实的总结

每个数据库的营销页在各自的维度上都是对的：D1 边缘快，Neon 有 Postgres，Supabase 有打包，Turso 有拓扑，Durable Objects 有保证。决策在于你的 SaaS 活在哪个维度上。对 2026 年 Workers 原生、读多写少的 SaaS，D1 是正确的默认。

如果你正在为 SaaS 评估数据库，看 TanStack Ship 功能页、D1 性能基准文章、D1 生产指南和 D1 深挖详解。想知道是哪次事故教会我写锁天花板的位置，看 D1 写锁复盘。更宏观的 SaaS 架构背景，看 SaaS 架构指南。

延伸阅读

• 4 小时零停机 D1 迁移：真实生产数据
• 多租户 SaaS 的 D1 实现：生产指南
• D1 查询优化：TTFB 快 67%，SEO 提升 31%
• D1 FTS5 全文搜索：50 万行上 47ms——无需外部服务
• 90 天延迟降低 62%：真实 Cloudflare 数据