数据库不需要"数据库服务器"了？
alitrack约 10 分钟● ● ●
① 钩子：一个"不需要数据库服务器"的数据库
2026 年初，Cloudflare 做了一个让数据库行业皱眉头的决定：把 SQLite——那个被戏称为"世界上部署最广的数据库"、却从来没有服务器可言的嵌入式数据库——正式变成了自己的核心存储底座，并开始按量收费。
这个决定有多"叛逆"？数据库产业过去四十年，几乎所有的商业逻辑都建立在同一套叙事上：你得有一台（或一群）数据库服务器。Oracle 卖的是服务器集群，PostgreSQL 卖的是运维服务，Snowflake 卖的是云上的"虚拟仓库"。没有服务器的数据库，在行业眼里根本不配叫数据库——它只是个"库文件"。
但 Cloudflare 反着来。他们的 Durable Objects（DO）把每个用户、每个文档、每个会话切成一个独立的 SQLite 小库，然后塞进覆盖全球 300 多个城市的边缘网络。你的数据不再住在"一台服务器"上，而是住在离你最近的三个机房同时出现。查询零延迟，数据三副本，写操作 10 秒内批量落到对象存储，白送 30 天任意时间点回滚。
于是那个经典的行业嘲讽——"SQLite 只是文件，不是数据库"——被 Cloudflare 硬生生掰成了卖点：正因为 SQLite 是文件，它才能被复制、被缓存、被塞进全球任何一台边缘机器，而不需要"数据库服务器"这个概念。
时间点也耐人寻味。DO 的 SQLite 存储 2025 年 4 月就已 GA，但真正的分水岭是 2026 年 1 月 7 日计费生效——Cloudflare 把它从"实验性玩具"扶正为"商业化主战略"：D1、Queues、Workflows、Agents SDK，全部长在 DO+SQLite 这一块地基上。
一个没有服务器的数据库，开始向有服务器的数据库们收钱了。
这当然值得写。但更有意思的问题在后面：如果"数据库不需要服务器"真的成立，那它到底是怎么做到的？开源世界跟上了吗？以及——还有谁，比 Cloudflare 更早地在做这件事？
● ● ●
② 解剖 SRS：三层架构如何"欺骗"SQLite
理解 Cloudflare 这套玩法，关键不在 SQLite——SQLite 四十年没怎么变过。关键在于它下面那层名为 SRS（Storage Relay Service） 的存储中继系统。2024 年替换掉旧的 KV 底层、为 D1 默默服役了一年多，核心思想只有一句话：
本地磁盘快但贵且会坏；对象存储便宜耐用但慢。用本地磁盘做缓存、对象存储做持久层——两者兼得。
SQLite 自己是不知道这件事的。它依然以为自己在读写一个普通文件。SRS 通过 hook SQLite 的 VFS（虚拟文件系统层）拦截每次文件写入，在幕后完成三层搬运：
第一层：WAL 变更日志，而非整个数据库
SQLite 强制开启 WAL 模式后，所有变更先写进 WAL 文件。SRS 截住这些变更，批量上传——最多攒 10 秒或 16MB 一批，避免产生海量小对象。同时，每当"上次快照以来的日志总量超过数据库本身大小"，就上传一次全库快照，把重建成本封顶在约 2 倍数据库大小。这个灵感直接来自开源项目 Litestream，但实现不同。
第二层：对象存储（R2）当"真相"，本地文件当缓存
数据库文件本身成了可丢弃的缓存：丢了就从对象存储重建。代价上限是"2× 数据库大小"的重放，换来的是无限便宜的持久层。
第三层：Output Gates——多写者的"顺序裁决官"
单机 SQLite 从来只有一个进程在写。上云后怎么办？SRS 让每次提交把变更日志发给跨 5 个不同数据中心的 follower，至少 3 个确认收到才返回写成功——打开 Output Gate。要丢一笔已确认的写入，需要"DO 主机 + 至少 3 个 follower"同时挂掉，也就是 ≥4 台机器、≥3 栋物理建筑同时完蛋。
这套组合拳的产出，是三个对开发者几乎免费的能力：
| 30 天 PITR 免费 |
注意那个 RPS 数字——500 到 1,000。这在云数据库世界里寒酸得像个笑话，但 Cloudflare 根本不在乎：它的设计意图是 scale out 而不是 scale up。每个用户、每个文档、每个会话都是独立的 DO 对象，单个对象撞到 1,000 RPS 墙？那就再切一个对象。这恰恰是官方文档自己教你的最佳实践："按每个逻辑单元一个对象"设计。
一句话总结 SRS：它没有发明分布式数据库，它发明了"把单机数据库云化"的搬运工。SQLite 还是那个 SQLite，只不过它的文件系统从一块磁盘，悄悄换成了全世界。
SRS 三层架构：本地缓存 + WAL 批量上传 + Output Gates，对象存储当真相
● ● ●
③ 转折：开源没有缺席——Celld 与"SQLite 云化"的三种姿势
看到这里你可能会想：又是云厂商的封闭玩法。DO 是专有的，SRS 是专有的，R2 是专有的——选型 DO 就等于终身绑定 Cloudflare，AWS、Azure、GCP 连等价物都没有。
这个判断在 2026 年 8 月 6 日之前是对的。那天，Deno 发布了 Celld（Apache 2.0）——目前唯一 1:1 的开源 DO 替代，而且野心不大不小，刚好戳在要害上：
你的 Workers/DO 代码原封不动，直接跑在 Celld 上。存储？每对象一个 SQLite，用 LTX 格式（Litestream 的复制格式）同步到你自己的 S3 兼容 bucket。协调？不需要控制平面，用 bucket 的 compare-and-swap lease 决定归属。
翻译成人话：Celld 就是"SRS 的开放实现"。技术栈 V8 + SQLite + LTX + Tokio，写确认前数据已落 bucket（RPO=0），单个 cell 内存开销约 4MB，空闲自动休眠，唤醒约 4ms。自托管成本约 $49/月——对比 Cloudflare 官方估算的 1 万 DO 约 $450/月。
更有意思的是它的姿态。Celld 官方原话大意是："DO 是 Kenton Varda 的杰作，这么棒的原语应该能在任何地方跑。"——不抵触 Cloudflare，甚至自己的官网就跑在 Cloudflare 上。开源社区没想掀桌子，他们只是想让这张桌子能搬回家。
于是"SQLite 云化"这个品类，2026 年夏天呈现出三种清晰姿势：
| 全托管 | |||
| 开源自托管 | |||
| 中间态 |
这三者的存在本身就是一个信号："嵌入式数据库 + 对象存储"已经从 Cloudflare 的私有发明，变成了整个行业认可的架构范式。当一个模式同时被云厂商（SRS）、开源新秀（Celld）、基础设施老兵（Litestream）验证，它就不再是某个公司的产品策略，而是技术演进的既定方向。
但先别急着下单。Celld 首版只有几天，生产项目仍应默认 Cloudflare，把 Celld 当"逃生舱 + 私有部署选项"。而且——注意我一直在说 SQLite。真正把"不需要数据库服务器"推向极致的，是另一个名字：DuckDB。
● ● ●
④ 主菜：DuckDB 才是真正的"服务器杀手"
SQLite 的故事讲的是"单机数据库上云"。而 DuckDB 讲的是另一件事——数据分析这件事本身，不需要数据库服务器。
DuckDB 从诞生起就是个"进程内"数据库：它不是一个独立运行的服务，只是一个函数库，嵌进你的程序里直接跑。在传统认知里，这种设计是"玩具"——数据分析不是应该跑在数仓集群上吗？直到 2026 年，DuckDB 用两个动作把这个认知彻底掀翻：
动作一：Quack 协议（2026-05-12）——远程查询，零服务器管理
Quack 是 DuckDB 官方的客户端-服务器协议：HTTP + Arrow，支持多写者并发。用法简单到不像数据库：
CREATE SECRET (TYPE quack, TOKEN '...', SCOPE 'quack:host');
ATTACH 'quack:host' AS remote; -- 一个远程 DuckDB
SELECT * FROM remote.sales;
注意区别：Quack 不是"又一个数据库服务器"。它是给"嵌入式引擎"装了个远程接口——你 ATTACH 的是一台机器上运行着的 DuckDB 进程，而不是一个需要你建账号、开端口、配权限的数据库服务。服务器这个中间层，被协议直接取代了。
动作二：DuckLake v1.0（2026-04-13）——湖仓格式，元数据进 SQL 库、数据进对象存储
DuckLake 是 DuckDB 官方发布的 lakehouse 格式，但它的设计哲学比 Iceberg/Delta 更"数据库"：元数据不存成一堆 JSON 文件，而是直接放进一个 SQL 数据库；数据文件照旧落在对象存储（Parquet）。于是快照、时间旅行、多版本这些能力，由数据库天然提供——20 万行写下去，对象存储里就是一个 1.7MB 的 Parquet 文件，元数据里一条快照记录，跨进程随时可读。
这两件事合起来就是一句话：DuckDB 官方自己把"云化"做完了。远程查询有 Quack，持久存储有 DuckLake，两者都开源、都免费、都原生支持对象存储。
而这恰恰把 MotherDuck 推入了尴尬境地。MotherDuck 是 DuckDB 的官方云服务，2025 年底到 2026 年初悄然调整定价：取消 $25/月的入门档，Business 从 $100 涨到 $250/月，免费额度大幅缩水。Reddit 数据工程板块一片逃离潮。逃去哪？答案就在标题里——既然 Quack + DuckLake 加起来就是自托管版的"MotherDuck"，$250/月 的账就算不下去了。
顺带说一个我最近亲手验证过的事实：我在自己的可视化工具里给面板加了 Quack 远程数据源支持，从配置到跑通只花了三个步骤——服务端一句 CALL quack_serve(...)，客户端一条 ATTACH，面板查询直接返回远程数据。整个过程中没有创建任何"数据库实例"，没有分配任何"服务器资源"。"数据库服务器"这个概念，在这些步骤里根本没有出场机会。
● ● ●
⑤ 决策框架：你的数据该"住"在哪？
聊到这里，一个现实问题摆上台面：既然"不需要数据库服务器"的选项越来越多，我的下一个项目到底该怎么选？
答案要看你的数据住在哪一层。按三个维度——写并发、数据量级、运维预算——对照：
三个信号帮你快速定位：
信号一：并发写多不多？
多人实时编辑同一份数据（聊天、协作文档、计数器）→ 要么全托管（SRS 帮你处理多写者），要么租户级单写者（Celld / Quack 分片）。只是分析查询、ETL 结果、报表 → 单机嵌入式或自托管云化都行，别为它付服务器钱。
信号二：数据量级过不过单机？
几十 GB 内、一台机器跑得动 → 嵌入式就是最优解，Quack 远程查询就够了。超过单机 → DuckLake/对象存储路线，数据文件与计算解耦，这才是湖仓该做的事。
信号三：你愿不愿意背运维？
愿意 → 自托管云化（$49/月级）换数据主权和确定性成本。不愿意 → 全托管，但记住 MotherDuck 的教训：平台的涨价，就是你的迁移窗口——所以无论选哪条路，都该保证数据能按开放格式（Parquet/SQLite 文件）随时搬走。
最后是我的个人判断：工具型产品走 Quack 远程数据源，分析型工作负载走 DuckLake 湖仓，低延迟边缘场景才轮到 SRS/Celld。 大多数项目真正需要的，是一台"数据库服务器"吗？不是——它们需要的是一份能随时打开、随时复制、随时上云的数据文件，外加一个能远程访问它的协议。
三种数据栖身之地：单机嵌入式 / 托管云 / 自托管云化
● ● ●
尾声：数据库的未来不是"服务器"，是"协议 + 文件"
SQLite 用四十年证明了一件事：一个文件可以是一个数据库。DuckDB 接着证明：一个进程内引擎可以是一个数据仓库。而 2026 年 Quack 和 DuckLake 的出现，把最后一块拼图补上了——协议 + 对象存储，可以是一个云。
服务器没有消失，但它在数据库故事里的角色，已经从"主角"降级成了"可选项"。Cloudflare 把 SQLite 塞进 300 多个城市不需要你操心服务器，Celld 让你把 DO 搬回家不需要服务器，Quack 让你直连远程 DuckDB 不需要服务器，DuckLake 让你的数据住在对象存储里不需要服务器。
这四十年里，每一代"数据库服务器"都曾被当作不可替代的昂贵基础设施。而每一次，都有人用更朴素的东西把它替换掉：先是文件，然后是进程内引擎，现在是协议。
所以下次立项时，值得问自己那个听起来有点叛逆的问题：
你的下一个项目，真的需要一台"数据库服务器"吗？
（全文完）
● ● ●
参考来源
Cloudflare 官方博客：Zero-latency SQLite storage in every Durable Object（SRS 架构详解） https://blog.cloudflare.com/sqlite-in-durable-objects/ DuckDB 官方：Quack 远程协议公告（2026-05-12）
https://duckdb.org/2026/05/12/quack-remote-protocol
DuckDB 官方：Quack 协议文档
https://duckdb.org/docs/current/quack/overview
DuckDB 官方：DuckLake v1.0 发布（2026-04-13）
https://ducklake.select/2026/04/13/ducklake-10/
Deno：Celld 开源仓库（Apache 2.0）
https://github.com/denoland/celld
MotherDuck 定价页（Business $250/月）
https://motherduck.com/pricing/
Litestream 官方文档（SRS 的灵感来源）
https://litestream.io/how-it-works/