HN 上今天出现了一条看起来像标题党的链接：
"SQLite Is a Library of Congress Recommended Storage Format"
535 分，161 条评论，20 小时前发布。不是标题党——这是真的。
美国国会图书馆（Library of Congress）在其"数字格式可持续性"项目中，将 SQLite 列为数据集（datasets）的推荐存档格式。而与此同时，讨论区有人爆料：一些企业明文禁止在内部使用 SQLite，因为"一个看起来像普通文件的数据库太容易携带 PII 数据到处跑了"。
一个国家级的数字存档机构说"这是最好的长期保存格式之一"。一个企业安全团队说"这东西太危险了必须封杀"。
两件事同时为真。这就是我今天要写的东西。
国会图书馆不是随便列名单的。他们有一套公开的评估框架，七个维度，每个维度都有明确的定义。
| 标准 | 定义 | SQLite 表现 |
|---|---|---|
| Disclosure 公开性 | 完整的技术规范是否存在且可获取 | ✅ SQLite 源代码完全公开，文件格式文档详尽到每一个 bit |
| Adoption 采纳率 | 格式被主要创造者和使用者采用的程度 | ✅ 地球上部署量最大的数据库引擎（每部手机、每个浏览器、每架飞机） |
| Transparency 透明度 | 数字表征是否能用基础工具直接分析 | ✅ 文件头清晰可辨，hexdump 即可读取基本结构，页面布局文档化 |
| Self-documentation 自文档化 | 是否包含描述性、技术性元数据 | ✅ 文件头包含版本号、页面大小、数据库大小等元信息 |
| External Dependencies 外部依赖 | 对特定硬件/操作系统/软件的依赖程度 | ✅ 零外部依赖——一个 C 文件，任何有编译器的平台都能读 |
| Patent Impact 专利影响 | 专利是否会阻碍存档机构的持续使用 | ✅ 公有领域（public domain），无专利障碍 |
| Technical Protection 技术保护机制 | 加密等机制是否会阻碍存档 | ✅ 默认无加密，存档机构可以完整访问内容 |
七个标准，SQLite 全部通过。在国会图书馆的数据集推荐存档格式列表中，除了 SQLite，只有三个文本格式：XML、JSON、CSV。也就是说，在所有数据库格式中，SQLite 是唯一一个被推荐的。
这件事从 2018 年 5 月 29 日就开始了。但直到今天才在 HN 上火起来。
为什么？因为 SQLite 一直在默默地做一件事：它把自己变成了一个不会被时间淘汰的文件格式。
HN 评论区最热的一个分支讨论是这样的：
"我见过一些公司明文禁止使用 SQLite。为什么？因为它太容易设置一个数据库了——你的应用关键组件看起来就像一个文件，一个可以复制到任何服务器上的文件。即使里面包含 PII 数据。把这个乘以你公司里的应用数量……"
— HN 用户
另一个人立刻反驳：
"那同一个公司也禁止 Excel 吗？Excel 电子表格经常在不可能的地方变成影子数据库。"
— HN 用户
这段对话暴露了一个荒谬的现实：
| SQLite | Excel | |
|---|---|---|
| 文件扩展名 | .db / .sqlite（看起来像数据库） | .xlsx（看起来像电子表格） |
| 内部结构 | B-tree 页面，关系型表，ACID 事务 | XML + ZIP，本质上也是结构化数据 |
| 携带 PII 的风险 | 高——一个文件包含完整数据 | 同样高——一个文件包含完整数据 |
| 企业态度 | 🚫 禁止使用 | ✅ 人人都有 Office，理所当然 |
| 存档能力 | ✅ 国会图书馆推荐 | ❌ 没有推荐（二进制格式，依赖微软） |
Excel 是"合法的影子数据库"——因为它看起来像办公文件。SQLite 是"危险的影子数据库"——因为它看起来像技术文件。
但两者的本质区别只在于：SQLite 的格式是公开的，Excel 的格式是微软私有的。
讽刺吗？企业安全团队封杀 SQLite 的理由（"看起来像个文件"）恰好也是国会图书馆选择 SQLite 的理由（"不需要特殊软件就能读取"）。
一个值得关注的讨论分支：有人分享了他把 SQLite 用作只读分发格式的架构——构建数据库、上传到 S3、永远不修改、通过 HTTP Range 请求远程查询。
"我们有一个系统会构建 SQLite 数据库并上传到 S3。一旦上传，它们永远不会被修改。构建程序只做写入，查询程序只做读取。它使用 VFS 通过 HTTP Range 请求原地查询数据库。"
— HN 用户
这个人承认 SQLite 不是最优方案——如果是从头设计，会针对 Range 请求优化读取模式，会并行读取。但他说了一句关键的话：
"但 SQLite 是权宜之选，而且我确信我永远都能读取这些文件。自定义格式就没有这个保障了。"
— HN 用户
这句话是整篇文章的核心。SQLite 的价值不是性能，不是功能，是"我确信 50 年后还能读取"。
这也解释了为什么国会图书馆选它——不是因为它是最好的数据库，而是因为它是最不可能消失的数据库。
评论区有人建议使用 Parquet + DuckDB 来做同样的事情（列式压缩、HTTP Range 请求）。这是一个技术上更好的方案。但有一个问题：Parquet 没有 SQLite 那种"一个文件就是一个完整数据库"的心智模型。Parquet 是分析格式，不是应用格式。
讨论中还出现了一个有趣的项目——有人做了一个叫 PeakSlab 的轻量级格式，声称比 SQLite 的 1.2MB WASM 小 97%（只有 38KB），专门用于 PWA 字典应用。
"SQLite 很好，但如果你不做写入，它真的是杀鸡用牛刀。所以我做了一个永远不会超越 SQLite 的格式，但它更轻更快。"
— PeakSlab 作者
SQLite WASM 的维护者立刻回应：1.2MB 是压缩后的数字，源码实际是 1.7MB（含文档），压缩后 310KB。然后 PeakSlab 作者承认自己的方案解决的是一个更窄的问题——PWA 字典应用。
这段插曲本身就是一个隐喻：在"轻量级"赛道上挑战 SQLite，就像在"简单"赛道上挑战 Unix——你会发现 SQLite 和 Unix 一样，它的"重"不是因为它臃肿，而是因为它解决了一堆你还没遇到的问题。
| 判断 | 确定性 | 时间线 |
|---|---|---|
| "存档即分发"成为 SQLite 的第二增长曲线——只读数据库作为数据交付格式（替代 CSV/JSON dumps） | 高 | 已在发生 |
| 企业封杀 SQLite 的政策将逐渐失效——因为 SQLite 已经嵌入到每一个操作系统、浏览器和移动设备中，封杀 SQLite 等于封杀整个计算基础设施 | 高 | 已经在松动 |
| Excel 的"影子数据库"地位将被 SQLite 侵蚀——当数据工程团队发现 SQLite 可以做 SQL 查询、有 ACID、且开源免费时 | 中高 | 2-3 年 |
| LoC 推荐格式列表将出现新成员——Parquet（列式分析）、DuckDB 格式可能在未来 5 年内加入 | 中 | 3-5 年 |
| "文件格式的可存档性"成为软件选型的新维度——不只是"功能/性能/成本"，还有"50 年后能不能读" | 中 | 1-2 年 |
想象一下：50 年后，一个研究人员打开一个 2026 年的 .db 文件。
不需要安装 Oracle。不需要配置 MySQL 服务器。不需要知道它当初是用 Python 还是 Node.js 创建的。只需要一个 SQLite 命令行工具——一个 1MB 的二进制文件——就可以查询里面的所有数据。
50 年后的 .xlsx 文件呢？微软还在吗？Excel 的格式变了几代？那个文件还能打开吗？
国会图书馆用脚投票选了 SQLite。不是因为它是技术上最优雅的数据库——D. Richard Hipp 自己会说"它只是够用"。而是因为它是一个不需要任何人批准就能永远读取的文件。
在数字世界里，这可能就是最接近"永生"的东西。
而那些禁止 SQLite 的企业安全团队——他们可能正在用 Excel 管理着最敏感的数据。 irony 拉满了。