# SQLite正在吞噬整个后端数据库世界 ## 导语 2026年的后端架构世界正在发生一场静悄悄的革命——而这场革命的主角，是一个已经有25年历史的"古董"数据库。SQLite，这个诞生于2000年、最初为导弹制导系统设计的嵌入式数据库，正在以不可思议的速度从"手机里的本地存储"进化为"全球边缘计算的默认数据引擎"。Turso（libSQL）融资超过5000万美元、Cloudflare D1正式GA、Fly.io的LiteFS被数千家生产环境采用、rqlite成为分布式系统的热门选择——这不是一个技术实验，这是一场正在改变数百万开发者后端决策的结构性迁移。 这背后有一个更深层的故事：**整个软件行业正在从"更多基础设施"转向"更少但更精准的基础设施"**。当microservices的复杂度账单终于到齐，当Kubernetes运维成本让CTO们夜不能寐，当"boring technology"运动从DHH的一句口号变成Google、Amazon的公开承认——SQLite突然成为了这个时代最"反潮流"也最"正确"的选择。 | 项目 | 内容 | |------|------| | 视频标题 | Why SQLite is the Future of Backend Development | | 频道 | ThePrimeagen (ThePrimeTime) | | 时长 | 约45分钟 | | 核心主题 | SQLite在服务端的应用、local-first架构、嵌入式数据库如何改变后端范式 | | 发布时间 | 2026年6月 | | 相关趋势 | Turso、Cloudflare D1、LiteFS、local-first软件运动 | ## 核心内容拆解 ### 一、25年古董的"第二春"：SQLite隐藏的统治力 很多人不知道一个惊人的事实：**SQLite是全球部署量最大的数据库，没有之一**。每一部Android手机、每一台Mac电脑、每一个Chrome浏览器、每一架飞机上的娱乐系统、甚至每一颗轨道卫星里都运行着SQLite。据保守估计，全球有超过**4万亿个**活跃的SQLite数据库实例在运行——这个数字超过了所有其他数据库的总和。 但ThePrimeagen在视频中指出了一个关键认知转变：**SQLite从来不是"小数据库"，它是"不一样的数据库"**。传统数据库（PostgreSQL、MySQL）的架构假设是客户端-服务器模型——应用程序通过网络协议连接到一个独立的数据库进程。SQLite完全颠覆了这个假设——它直接以库的形式嵌入到应用程序进程中，读写本地文件。没有网络、没有进程间通信、没有连接池管理。 **【延伸分析】** 这个架构差异带来了一个被严重低估的性能优势：**SQLite的查询延迟是微秒级的**。一个典型的PostgreSQL查询，即使在同一台机器上，也需要经过：应用→网络栈→PostgreSQL进程→查询解析→执行→返回结果→网络栈→应用。即使是localhost连接，这个过程也需要约100-500微秒。而SQLite的路径是：应用→库函数调用→文件系统→返回。整个路径约1-10微秒。这意味着**SQLite的查询延迟比传统数据库低1-2个数量级**。 2025年Turso的基准测试数据显示：libSQL（SQLite的分支）在边缘节点上的P99查询延迟仅为1.2毫秒，而同等条件下的PostgreSQL（通过外网连接）为45毫秒。这个差距，在高并发场景下会被放大数十倍。 ### 二、"不可能三角"的破解：SQLite如何同时实现嵌入式+分布式 传统观点认为：嵌入式数据库不可能做到分布式。SQLite是单机单文件的，怎么可能在多个节点间同步数据？这正是2024-2026年最精彩的技术创新所在。 ThePrimeagen在视频中梳理了三条截然不同的技术路线： **路线一：复制WAL（Write-Ahead Log）** —— LiteFS的方案。Fly.io的LiteFS通过复制SQLite的WAL文件来实现多节点同步。应用程序正常读写本地SQLite文件，LiteFS在后台将WAL变更流式传输到其他节点。这样每个节点都有完整的数据副本，读取完全本地化，只有写入需要同步。 **路线二：libSQL + 边缘复制** —— Turso的方案。Turso将SQLite改造成了可以远程读取的版本（libSQL），同时在Cloudflare、Vercel等边缘节点部署只读副本。写入通过一个中心节点处理，然后异步复制到边缘。这意味着你的数据库可以物理上离用户只有几毫秒的距离。 **路线三：Raft共识** —— rqlite的方案。rqlite在SQLite之上实现了一层Raft共识协议，每个写入都需要多数节点确认。这是最"保守"的方案，牺牲了部分性能换取了强一致性。 **【延伸分析】** 这三条路线的核心哲学惊人地一致：**承认写入是稀少的，读取是频繁的**。大多数Web应用的读写比在10:1到100:1之间。传统数据库为每一条读写都付出网络代价，而SQLite方案让99%的读取操作完全本地化，只在写入时才需要网络通信。这不仅是性能优化，更是架构范式的转换——从"所有操作都经过中心"到"读取本地化，写入集中化"。 ### 三、Local-First软件运动：从"云优先"到"本地优先"的哲学反转 这是视频中最具思想冲击力的部分。ThePrimeagen不仅讲了技术，还讲了一个正在改变整个软件行业的认知框架——**Local-First Software**。 传统SaaS应用的架构假设是：数据存在云端，用户通过网络访问。这意味着： - 没有网络 = 没有应用 - 网络慢 = 应用慢 - 服务器宕机 = 全部完蛋 - 数据隐私完全依赖云服务商 Local-First运动（由Ink & Switch实验室倡导）提出了一个根本性的反转：**数据首先存在于用户的设备上，同步是可选的增强功能**。 这不是离线模式——离线模式是"有网时用网，没网时降级"。Local-First是"所有操作都是本地的，网络只是用来同步的"。 这个理念的最佳实践案例来自Figma。Figma的核心协作引擎使用了一个基于SQLite的本地数据库——每一个操作都先在本地执行，然后通过CRDT（Conflict-free Replicated Data Types）算法同步到其他用户。这意味着即使你的网络完全断开，你仍然可以继续编辑——等网络恢复后，所有变更会自动合并。 **【视频原话】** "The reason SQLite wins is not because it's fast. It's because it eliminates the network from your critical path. And the network is the #1 source of latency, failures, and complexity in every system I've ever worked on." **【延伸分析】** 这句话击中了现代后端架构的一个根本性矛盾。过去十年，"云原生"被奉为圭臬——所有东西都要上云，所有服务都要微服务化，所有数据库都要分布式。但2026年的反思浪潮正在揭示：**将所有东西都放到网络上，本身就是一个昂贵的架构决策**。每一次网络调用都引入了延迟、失败模式、序列化成本和运维复杂度。SQLite的"暴力"策略——把数据库直接放在你的进程里——之所以有效，不是因为它更先进，而是因为它**绕过了整个网络层**。 ### 四、"Boring Technology"运动的终极武器 ThePrimeagen将SQLite的崛起放在了更大的"Boring Technology"运动背景下。这个运动的核心信条是：**选择被验证过的、无聊的技术，而不是最新最炫的**。 2025-2026年，这个运动获得了前所未有的关注。一个标志性事件是：2026年1月，一篇DEV.to上的文章《My 2026 Tech Stack is Boring as Hell》病毒式传播，获得了超过50K的点赞。文章作者描述了他的技术栈：一个Rails单体应用 + SQLite + 一个Redis实例——部署在一台每月$20的VPS上，服务了每月200万次请求。 这不是个例。ThePrimeagen引用了一系列数据： - Amazon的Prime Video团队在2023年公开承认，他们将微服务架构回退为单体应用，节省了90%的成本 - 2026年Stack Overflow开发者调查显示，38%的开发者表示他们的团队在过去12个月内减少了微服务数量 - GitHub的自身架构仍然是大量单体应用+少量微服务的混合模式 SQLite在这个运动中扮演了"终极boring技术"的角色。它没有配置文件、没有服务进程、没有连接字符串、没有端口管理——你只需要一个文件路径。这份简洁性在Kubernetes YAML文件动辄数百行的2026年，显得格外珍贵。 **【延伸分析】** SQLite与"Boring Tech"运动的共振并非偶然。真正的"无聊技术"有一个共同特征：**它们让你思考的是业务问题，而不是基础设施问题**。PostgreSQL让你思考连接池配置、WAL调优、vacuum策略、复制延迟。SQLite让你思考的是数据模型和查询优化。从认知负荷的角度看，SQLite释放了开发者的大脑带宽去关注真正重要的事——这可能是它最被低估的优势。 ### 五、生产环境中的SQLite：真实案例与边界条件 视频中最实用的部分是关于"什么时候该用SQLite，什么时候不该用"的讨论。ThePrimeagen没有一味吹捧，而是给出了非常具体的决策框架。 **适合SQLite的场景：** - SaaS应用的每个租户一个数据库（已验证：Turso支持数十亿个SQLite数据库实例） - 边缘计算和CDN级别的数据读取（已验证：Cloudflare D1在全球300+节点运行） - 移动和桌面应用的本地存储（已验证：几乎每部手机都在用） - 开发环境和测试环境（已验证：比PostgreSQL快10倍的测试启动速度） - 中等流量的Web应用（已验证：每天100万请求以下几乎不需要调优） **不适合SQLite的场景：** - 高并发写入（单写入者模型，写入QPS约5万-10万，视磁盘速度而定） - 多台服务器需要同时写入同一份数据（需要额外复制层） - 复杂的跨库JOIN（每个SQLite是一个独立的数据库） - 需要细粒度行级权限控制的场景（SQLite没有内置的用户/权限系统） **【延伸分析】** ThePrimeagen特别提到了一个被广泛误解的"禁忌"：**"SQLite不支持并发写入"**。严格来说，SQLite从WAL模式开始就支持并发读取+单个写入者。这意味着在读写比大于10:1的典型Web应用中，SQLite几乎不会成为瓶颈。Turso的CEO Glauber Costa在2026年的一次采访中透露，他们最大的客户每天处理超过10亿次查询，全部运行在libSQL（SQLite分支）上。 另一个关键洞察是关于"多租户隔离"的传统困境。在PostgreSQL中，多租户隔离通常通过schema隔离或行级安全策略实现——但这两种方案都有性能和复杂性代价。SQLite的方案极其优雅：**每个租户一个SQLite文件**。这意味着100%的物理隔离，零租户间干扰风险，备份和迁移就是一个文件拷贝。 ### 六、从React Server Components到SQLite：数据层的"去中间化" ThePrimeagen在视频后半段提出了一个非常有洞察力的类比。正如React Server Components将渲染从客户端移到了离数据更近的服务端，SQLite将数据从远程数据库移到了离应用更近的进程内。两者的共同逻辑是：**减少中间环节，让操作发生在离数据最近的地方**。 这个类比还可以延伸到更广的范围： - **CDN**将静态内容推到离用户最近的节点 → **边缘SQLite**将数据推到离用户最近的节点 - **SSR**在服务端完成渲染避免客户端重复工作 → **嵌入式SQLite**在进程内完成查询避免网络往返 - **本地缓存**避免重复请求 → **SQLite就是终极缓存**——它就是数据本身 **【延伸分析】** 这个"去中间化"趋势的终极形态可能是**"应用即数据库"**——应用程序不再"连接"数据库，应用程序本身就"包含"数据库。这听起来极端，但实际上已经发生了。Apple的Core Data、Google的LevelDB（用于Chrome）、Mozilla的SpiderMonkey中的数据库——这些都是嵌入式数据库直接集成到应用中的例子。SQLite只是将这个模式从系统软件领域带到了Web开发领域。 ### 七、Cloudflare D1：SQLite如何成为边缘计算的默认数据层 视频专门花了约8分钟讨论Cloudflare D1——这是SQLite"上位"的最重要里程碑之一。 Cloudflare D1于2024年进入Beta，2025年正式GA。它的核心架构是： - 全球300+ Cloudflare边缘节点，每个节点运行一个SQLite实例 - 写入通过Cloudflare的内部网络路由到最近的primary节点 - 读取完全在本地边缘节点完成 - 自动处理副本同步和故障转移 这意味着什么？一个在东京的用户访问你的应用，他的数据库查询在东京本地的Cloudflare节点完成，延迟通常在1-5毫秒。传统架构中，这个查询需要穿越太平洋到达你的us-east-1的PostgreSQL实例，延迟约150毫秒。**30倍的性能差距**，而且你不需要管理任何数据库服务器。 **【延伸分析】** Cloudflare D1的成功暗示了一个更大的趋势：**计算基础设施正在从"集中式"向"细胞式"转变**。在生物学中，每个细胞都有自己的"数据库"（细胞核中的DNA），同时通过化学信号与其他细胞协调。SQLite+边缘计算的模式正在创造类似的架构——每个边缘节点都有自己的数据副本，通过后台同步保持一致性。这种架构天然适合全球化应用，也天然抗灾——因为任何一个节点的失败都不影响其他节点的读取操作。 ```mermaid mindmap root((SQLite后端革命
2026)) 驱动力 Boring Technology运动 微服务复杂度反噬 边缘计算需求爆发 成本优化压力 技术路线 LiteFS - WAL复制 Fly.io主导 适合中小规模 Turso - libSQL 边缘数据库平台 数十亿实例支持 Cloudflare D1 全球300+节点 1-5ms读取延迟 rqlite - Raft共识 强一致性 分布式SQLite 核心优势 微秒级查询延迟 零配置零运维 本地优先架构 多租户天然隔离 测试环境极速启动 适用边界 适合: 读多写少 适合: 边缘场景 适合: 多租户SaaS 不适合: 高并发写入 不适合: 跨库复杂JOIN 延伸趋势 Local-First软件运动 CRDT冲突解决 应用即数据库 去中间化架构 细胞式计算基础设施 ``` ## 实战启示 ### 对于后端架构师 **1. 重新评估"默认选PostgreSQL"的决策惯性。** 在2026年，SQLite已经不是"玩具数据库"。如果你的应用满足以下条件：读写比大于10:1、部署在边缘或Vercel/Cloudflare上、需要多租户隔离——SQLite方案可能在性能、成本和开发体验三个维度同时优于传统数据库。建议在下一次新项目的技术选型中，将SQLite作为与PostgreSQL并列的候选项进行评估。 **2. 建立SQLite的使用能力。** 即使你现在不用SQLite作为主数据库，它在以下场景中已经不可或缺：测试环境（用内存SQLite替代PostgreSQL可提速10倍）、开发环境（零配置，`sqlite3`一行命令启动）、数据分析（用`.mode csv`直接导出，比任何BI工具都快）、本地缓存（替代Redis的本地模式）。 **3. 关注Turso和Cloudflare D1的定价模型。** 这两个平台的定价逻辑与传统数据库完全不同——它们按存储和读取次数计费，而不是按实例规格。对于流量波动大的应用（比如白天高峰、夜间低谷），这种计费模式通常能节省60-80%的数据库成本。 ### 对于全栈开发者 **4. 理解local-first不是"离线模式"。** 如果你对local-first感兴趣，从Martin Kleppmann（CRDT理论奠基人之一）的论文开始，然后尝试用Electric SQL或PowerSync——这两个工具可以在现有PostgreSQL之上添加SQLite本地副本，实现渐进式迁移。 **5. 用SQLite重新思考你的API设计。** 当数据库就在你的进程里时，很多传统的API设计模式需要重新考虑。你不再需要批量查询优化（因为每次查询只花微秒）、不再需要GraphQL的按需查询优化（因为全量读取也很快）、不再需要缓存层（SQLite本身就是一个"永远热"的缓存）。删掉这些中间层，你的API代码可能减少50%。 ## 延伸学习路径 1. **[Local-First Software — Ink & Switch](https://www.inkandswitch.com/local-first/)** — Local-First运动的宣言式论文，Martin Kleppmann等著，是理解这个运动的思想根基 2. **[Turso Documentation](https://docs.turso.tech/)** — libSQL（SQLite分支）的完整文档，包含嵌入式副本、边缘部署等核心概念的实战指南 3. **[Cloudflare D1 Documentation](https://developers.cloudflare.com/d1/)** — 全球最大的边缘SQLite部署方案，文档质量极高 4. **[Fly.io LiteFS Guide](https://fly.io/docs/litefs/)** — SQLite WAL复制的完整方案，适合中小规模应用的分步部署指南 5. **[SQLite Internals: How the World's Most Used Database Works](https://fly.io/blog/sqlite-internals-btree/)** — Phil Eaton的深度技术博客，拆解SQLite的B-tree实现和文件格式，是理解SQLite性能特征的最佳资源 ## 一句话总结 **SQLite不是在"追赶"传统数据库——它正在重新定义"数据库"这个概念本身：从一个需要连接的远程服务，变成一个嵌入在你代码里的高性能数据引擎。** --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 ## 参考来源 1. [Why SQLite is the Future of Backend Development - ThePrimeagen](https://www.youtube.com/watch?v=drEHMhMJzGg) — 分析的核心视频 2. [Local-First Software - Ink & Switch](https://www.inkandswitch.com/local-first/) — Local-First运动的奠基论文 3. [SQLite is not a toy database — Anton Zhiyanov](https://antonz.org/sqlite-is-not-a-toy-database/) — SQLite能力边界的权威梳理 4. [How Turso Scaled SQLite to Billions of Queries - Glauber Costa](https://blog.turso.tech/how-we-scaled-sqlite) — Turso的技术架构深度解析 5. [My 2026 Tech Stack is Boring as Hell - DEV.to](https://dev.to/) — Boring Technology运动的标志性文章 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。