SQLite：万能数据库解决方案

# SQLite 适用于一切场景 | JoeCode 来源：https://joecode.com/2026-08-19-sqlite3/ 关于 (https://joecode.com/) 联系方式 (https://joecode.com/contact) 简历 (https://joecode.com/resume) 噪音 (https://joecode.com/noise) 书签 (https://joecode.com/links) [\[Solis\]](https://joecode.com/solis) ## SQLite 适用于一切场景 *2026年8月19日* Raphael Bauer 博士写了一篇精彩的文章*《PostgreSQL 适用于一切场景 (https://www.raphaelbauer.com/posts/postgresql-everything/)》*，探讨了使用 PostgreSQL 驱动企业级应用的价值。我冒昧地纠正了其中几个错误，主要是他应该选择 SQLite 😊（这主要是个玩笑，我 ❤️ PostgreSQL，这是项伟大的技术。） 与普遍看法相反，解答一切的答案不是42，而是 SQLite。（好吧，也可能是 `sqlite3`。） ## 目录 - 引言 (https://joecode.com/2026-08-19-sqlite3/#intro) - 坚如磐石，稳定可靠 (https://joecode.com/2026-08-19-sqlite3/#rock-solid-and-stable) - 轻松运行、安装与扩展 (https://joecode.com/2026-08-19-sqlite3/#easy-to-run-install-and-scale) - 简化你的IT架构 (https://joecode.com/2026-08-19-sqlite3/#simplifies-your-it-setup) - SQLite 替代 Solr 和 Elasticsearch：全文搜索 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replaces-solr-and-elastic-full-text-search) - SQLite 替代 MongoDB：卓越的JSON支持 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replaces-mongodb-excellent-json-support) - SQLite 替代 Kafka 和 RabbitMQ：SQLite 作为队列 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replaces-kafka-and-rabbitmq-sqlite-as-a-queue) - SQLite 替代 ClickHouse：处理高吞吐量时序数据 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replaces-clickhouse-high-volume-time-series-data) - SQLite 作为向量数据库用于 AI 工作流 (https://joecode.com/2026-08-19-sqlite3/#sqlite-as-vector-database-for-ai-workflows) - SQLite 替代 Redis：非持久化高性能缓存 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replaces-redis-non-persistent-high-performance-caching) - SQLite 替代文件系统：存储原始数据 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replaces-the-file-system-for-raw-data) - SQLite 替代你的图数据库 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replacing-your-graph-database) - SQLite 替代你的微服务 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replacing-your-microservice) - SQLite 替代你的 PlayStation 5 (https://joecode.com/2026-08-19-sqlite3/#sqlite-replacing-your-playstation-5) - 结论 (https://joecode.com/2026-08-19-sqlite3/#conclusion) ## 引言 SQLite 的寿命将超过你现在运行的大多数东西。 过去，人们普遍认为 SQLite 只是个玩具。一个文件。一个你打包进手机应用里，这样就不用写配置解析器的东西。真正的应用程序应该使用真正的数据库，带有真正的端口号、真正的守护进程，以及真正的凌晨3点报警。 依我之见，SQLite 的强大之处源于三点： 1. **坚如磐石，稳定可靠。** 2. **轻松运行、安装与扩展。** 主要是因为没什么需要运行的。 3. **它极大地简化了你的IT架构**，因为它不仅是一个关系型数据库管理系统（RDBMS），还是一个全文搜索引擎、一个文档存储、一个缓存、一个向量索引，以及一种文件格式。 让我们仔细看看。 ## 坚如磐石，稳定可靠 SQLite 是项老旧但成熟的技术。首次发布于2000年。同时，它也是迄今为止全球部署最广泛的数据库引擎，领先幅度巨大。它存在于你的手机、浏览器、汽车里，甚至你乘坐的飞机上。SQLite 运行实例的数量比其他所有数据库运行实例的总和还要多，而且这不是一场势均力敌的竞赛。 修复数据库系统的漏洞需要时间。SQLite 拥有这段时间，并且持续发展至今。其测试套件在 MC/DC（修改条件/判定覆盖）标准下达到了 100% 的分支覆盖率，这是航空电子软件所采用的相同标准。测试代码量大约是库代码的 500 倍。该项目明确承诺支持到 2050 年，这比你公司的使命宣言规划的视野还要长远。 它还是公有领域的。不是开源，是公有领域。没有许可证、没有贡献者许可协议（CLA）、没有归属条款、没有拿到C轮融资后就改变主意的供应商。 诚然，SQLite 很老。但它持续默默地发布着现代特性：窗口函数、`RETURNING` 子句、严格表（strict tables）、生成列（generated columns）、`jsonb`。每一次发布都是一次微小、经过充分测试、向后兼容的改进，这是数据库能成为的最不令人兴奋但最有价值的东西。 ## 轻松运行、安装与扩展 在本地安装 SQLite 非常简单，简单到你已经完成过了。它与每个主要 Linux 发行版捆绑，内置于 Python、Ruby、PHP、Go、Rust、.NET、Android 和 iOS 中，现在就静静地坐在你的 Mac 上，不管你是否主动要求过。 在与生产环境完全相同的数据库上运行测试在这里不是个 Test containers 问题。它是 `:memory:`。你的测试套件能在微秒内（每个测试）并行地启动一个全新的数据库，无需 Docker 守护进程，也不会有端口冲突。你测试的东西就是你发布的东西，因为它们是同一个库编译进同一个二进制文件。 如果你想在服务器上运行 SQLite：你已经在运行了。它随操作系统而来。 扩展性是人们期望文章变得含糊其辞的地方，但我们不这样： - **垂直扩展：** 一个现代 NVMe 驱动器和一台配备 128GB 内存的机器，当你的数据库往返是函数调用而非网络跳转时，能处理惊人的流量。无需连接池。无需 TLS 握手。无需 `pgbouncer`。纳秒级而非毫秒级。 - **复制与备份：** Litestream 持续将你的 WAL（预写日志）流式传输到 S3。LiteFS 为你提供分布式读取。两者都是小型的、单一二进制文件的、可靠的方案。 - **托管服务：** 如果你喜欢有控制面板，Turso、Cloudflare D1、rqlite 等服务很乐意卖给你带有控制面板的 SQLite。 这使得 SQLite 成为当今支持最广泛的软件之一。对你而言，这意味着更少的维护工作和更多时间为客户构建功能。 ## 简化你的IT架构 在云端运行 SQLite 是零点击操作，因为它就是应用程序旁边的一个文件。但不仅如此。SQLite 可以替代你原本需要运行的一整套系统。 ## SQLite 替代 Solr 和 Elasticsearch：全文搜索 SQLite 内置了 FTS5，这是一个全内置在你已链接的库中的全文搜索引擎。分词器、前缀查询、短语查询、`NEAR`、布尔运算符、支持 BM25 的自定义排名，以及用于渲染结果的片段/高亮函数。 这里有两点值得赞赏。首先，没有同步问题，因为没有第二个系统。你的搜索索引和数据在同一个事务中更新，从定义上讲，永远一致。你曾遇到的每一次“为什么搜索索引过时了”事件，都是由你不需要的架构引起的。 其次，它的速度快得令人惊讶。Simon Willison 的 Datasette 能够在多GB大小的 SQLite 文件上运行分面全文搜索，在小型虚拟机上免费实现毫秒级响应。 FTS5 能做多语言分析链和跨40个节点的分布式分片吗？不能。你有40个节点吗？也没有。 更多信息：[SQLite FTS5 文档 (https://sqlite.org/fts5.html)] ## SQLite 替代 MongoDB：卓越的JSON支持 SQLite 对存储和查询 JSON 有出色的支持。JSON 函数是内置的，`->` 和 `->>` 操作符按你希望的方式工作，而且从 3.45 版本开始有了 `jsonb`，一种二进制表示，避免了每次访问时的重新解析。 人们忽略的部分是：你可以对 JSON 进行索引。从 JSON 路径创建一个生成列，索引该生成列，你就得到了对模式（schema）中不存在字段的快速查找。无模式写入、带索引的读取、一个文件。 所以它的优势是：文档存储、ACID 事务、无需单独的服务器、无需副本集、无需分片配置、无需 `mongod`，而磁盘上的东西是一个你可以复制的单一文件。MongoDB 还有存在的必要吗？曾经有一篇关于大型出版社从 Mongo 迁移出来的文章。值得注意的是，从来没有人写过相反的文章。 ## SQLite 替代 Kafka 和 RabbitMQ：SQLite 作为队列 事件、队列和持久化日志每年都变得越来越重要。Kafka、RabbitMQ 和 SQS 都提供这些功能。维护它们很烦人、需要定制，并且需要专门的技能来招聘。 好消息：一张表就足够了。 ``` BEGIN IMMEDIATE; UPDATE jobs SET status = 'running', worker = ? WHERE id = (SELECT id FROM jobs WHERE status = 'pending' ORDER BY id LIMIT 1) RETURNING *; COMMIT; ``` `BEGIN IMMEDIATE` 提前获取写锁，`RETURNING` 返回你认领的行，事务保证只有一个工作进程获取到它。在 WAL 模式下，读取器从不阻塞，因此你的仪表板查询队列深度不会与你的工作进程冲突。 这里有一个诚实的提醒，因为你值得知道：SQLite 是单写入者。没有 `SKIP LOCKED`，因为没什么可跳过的。并发消费者在写锁上序列化，如果你的入队速率真的达到每秒数万次，你会感受到影响。 但请注意发生了什么。在这个论点的 PostgreSQL 版本中，队列是你数据库中的一张表。在这个版本中，队列是你数据库中的一张表，同时也是你应用程序进程的一部分。消息从未离开过这台机器。没有消息代理、没有消费者组再平衡、没有“为什么在部署期间分区分配改变了”。 我的建议：从 SQLite 开始作为你的队列。当它停止性能表现时，你将得到真实的数据而不是一种感觉，然后你可以充满信心地去买 Kafka。你会惊讶于这能坚持多久。 ## SQLite 替代 ClickHouse：处理高吞吐量时序数据 时序数据很特殊。大量数据点快速到达，然后是聚合、统计、汇总。 这里没有 TimescaleDB，所以让我们直截了当。SQLite 能提供的是： - **按文件分区。** 每天、每周或每个租户一个数据库。归档是 `mv`。删除旧数据是 `rm`，它常数时间运行且不会真空整理。跨它们查询是 `ATTACH` 加上一个 `UNION ALL` 视图。这很粗糙，但也极其有效。 - **汇总表** 由触发器或执行插入的同一代码路径写入。反正你迟早要构建持续聚合。 - **批量写入。** 一个事务，一万次插入，一次 fsync。在普通硬件上，SQLite 用这种方式能达到每秒几十万行，因为路径中没有网络协议。 - **需要时转向列式存储。** 对于分析那一半，直接指向你的 SQLite 文件运行 DuckDB。它原生读取。你可以对你的应用写入的同一个文件进行向量化 OLAP 分析，无需 ETL。 专业系统确实非常出色，如果你每秒摄入一百万个数据点，你应该去用一个。大多数说“时序数据”的人指的是每天几百万行，这对于 SSD 上的文件来说只是个平常的周二。 ## SQLite 作为向量数据库用于 AI 工作流 `sqlite-vec` 是一个无依赖、单文件的扩展，将 SQLite 变成一个向量数据库。它用 C 编写，可以在任何 SQLite 运行的地方运行，包括通过 WASM 在浏览器中运行，并将向量存储在普通表中。 这是 SQLite 具有不公平优势的部分。你的嵌入向量、源文档、元数据和全文索引都在同一个文件中，所以混合搜索是一个联接（join），而不是跨三个具有不同一致性模型的服务的分布式查询。用一个语句、事务性地按租户、日期、关键词和向量相似性进行过滤。 此外，这比听起来更重要：你的整个 RAG（检索增强生成）索引是一个文件。你可以通过电子邮件发送它。你可以把它放进 Docker 镜像里。你可以把它送到一台离线的笔记本电脑上。试试用你的托管向量集群做这个。 ## SQLite 替代 Redis：非持久化高性能缓存 缓存很重要。大多数应用程序使用 Redis 来保存会话和热数据。缓存本质上允许丢失数据并从源重新生成。 那么为什么要为此运行第二台服务器呢？SQLite 为你提供了几种选择，取决于你愿意牺牲多少持久性： ``` PRAGMA journal_mode = WAL; PRAGMA synchronous = OFF; -- 这是缓存，活得轻松点 ``` 或者完全跳过磁盘，使用 `:memory:`，或 `PRAGMA temp_store = MEMORY`，或一个通过 `file:cache?mode=memory&cache=shared` 在你的连接间共享的内存数据库。 过期是一个列和一个在定时器上运行的 `DELETE ... WHERE expires_at < unixepoch()`，这本来就是 Redis 在做的事情，只是更远，并且有它自己的淘汰策略，你得去研究一下。 关键点在于：Redis 通过 localhost 的 `GET` 大约在 100 微秒级别。SQLite 针对温页缓存的点查询大约在 1 微秒级别。你移除一个依赖并没有变慢，而是变快了，因为最快的网络调用就是那个函数调用。 Redis 是优秀的软件。但它也是一个单独的进程、一种单独的故障模式、一个单独的内存预算、一件需要单独保护的东西，以及一行单独的支出项。 ## SQLite 替代文件系统：存储原始数据 你会认为从文件中读取一个小的数据块比从数据库中读取更快。事实并非如此，这不是个人观点，这是 SQLite 项目发布的一个基准测试，并以令人钦佩的直率标题命名：*比文件系统快35%*。 对于大约 100KB 以下的数据块，SQLite 的读写速度比磁盘上的单个文件更快，并且额外节省了约 20% 的空间。原因是文件系统对每个项目都收取 `open()` 和 `close()` 以及目录遍历的费用，而 SQLite 只收取一个已经打开的文件句柄和一次 B-tree 查找的费用。 你还免费获得了：原子性的多数据块更新、崩溃时无部分写入、无文件名转义错误、无“当一个目录有400万个条目时会发生什么”的问题、无因 inode 数量导致 rsync 需要六小时的问题，以及一个备份方案就是一个文件。 将负载存储在 `BLOB` 列中，如果你觉得花哨可以用紧凑的格式序列化，在客户端反序列化。SQLite 团队自己表示 SQLite 是更好的 `fopen()`，他们将其作为一个设计目标，而不是开玩笑。 ## SQLite 替代你的图数据库 在 SQL 中通过递归查询处理分层数据是可行的，但历来难以阅读、维护和调试。 SQLite 完全支持递归 CTE，并且它在这个主题上的文档确实是该领域最好的技术写作之一。闭包表、物化路径和邻接表都能很好地工作。没有 `LTREE`，所以物化路径是 `TEXT` 列加上一个 `GLOB` 索引，这不那么优雅但大致一样快。 对于真正的图工作，`simple-graph` 用几百行 SQL 在普通 SQLite 表上实现了一个属性图。节点、边、遍历。 普遍原则在这里比在其他任何地方都更适用：你的图大概有十万个节点。十万个节点能放入 L3 缓存。你不需要 Neo4j。你需要一个索引和一杯咖啡。 ## SQLite 替代你的微服务 如今大多数“微服务”都是：一个模型、一个查询、输出 JSON。 SQLite 用 `json_object()` 和 `json_group_array()` 将任何查询转换为 JSON。这就是你的序列化层，消失了。 但 SQLite 比原始论证走得更远，因为 SQLite 运行在*你的进程内*。微服务不是被存储过程替代，而是被函数调用替代。没有需要部署的服务、没有健康检查、没有重试逻辑、没有熔断器、没有需要关联的分布式追踪，也没有被网络抖动主导的 p99 延迟。 Datasette 是将概念验证推向其结论的证明：指向一个 SQLite 文件，你就得到一个 JSON API、一个 Web UI、一个完全托管的界面，无需编写前端，甚至无需编写后端。它只是指向你的 SQLite 文件，然后呢？它就成了你整个系统的界面。