Simon Willison 在 2026 年 6 月 21 日发布了 sqlite-utils 4.0rc1。它是 sqlite-utils 4.0 的 release candidate，不是正式稳定版。
sqlite-utils 的定位也要先说清：它不是 SQLite 本体，而是一个用于操作 SQLite 数据库的 Python CLI utility and library。很多人用它导入 CSV、整理 JSON、更新表、生成可发布的 SQLite 文件。
这次有意思的地方，不是版本号从 3.x 走向 4.0。Willison 在相关文章 《sqlite-utils 4.0rc1 adds migrations and nested transactions》 里点出的两项变化，正好打在脚本工具最容易变乱的地方：表结构怎么演进，事务边界怎么组合。
我的判断很简单：这不是一次“SQLite 变强”的新闻，而是 sqlite-utils 开始更认真地处理小型数据工程里的秩序问题。
这次补的不是大功能，是脚本长期运行后的秩序
sqlite-utils 过去的优势是低摩擦。命令行能跑，Python 里也能调。对个人项目、数据整理、Datasette 相关流程、CI 生成数据库文件这些场景，它比上完整 ORM 轻得多。
但轻工具也有代价。
很多 SQLite 文件一开始只是临时容器。脚本跑久了，表结构就成了隐性契约：某个字段有没有加，某个索引有没有建，某台机器上的数据库是不是旧版本。靠几段 if table exists 和手写初始化逻辑撑着，迟早会乱。
migrations 解决的就是这个问题。它至少表明 sqlite-utils 4.0 想把“数据库结构走到哪一步”变成显式状态，而不是散在脚本里的临时判断。
nested transactions 处理的是另一类麻烦。数据脚本常常会被拆成多个函数：一个导入数据，一个清洗字段，一个补索引。每个函数都可能想开事务。外层脚本再开事务时，边界就容易打架。
嵌套事务的价值，在于让这些函数更容易组合。特别是批量导入、增量更新、失败回滚这类场景，事务边界清楚一点，脚本就少一点脆弱。
| 变化 | 它解决什么 | 更影响谁 | 我的判断 |
|---|---|---|---|
| migrations | 表结构演进缺少记录 | 长期维护 SQLite 文件和脚本的人 | 对“跑一次就丢”的脚本意义不大，对长期链路有价值 |
| nested transactions | 多层函数调用里的事务边界冲突 | 把数据库操作封装成多个函数的开发者 | 重点是可组合性，不是性能叙事 |
| release candidate | 4.0 正式版前的候选版本 | 已有 sqlite-utils 依赖的团队或个人 | 适合试迁移，不适合直接替生产依赖 |
这个边界要守住。它更像轻量数据工具的工程化补丁，不是 ORM 竞争宣言。
最该动的是两类人：脚本维护者和自动化链路使用者
如果只是偶尔用 sqlite-utils 转一次 CSV，4.0rc1 不急。等正式版、等文档稳定，成本更低。
更该测试的是两类人。
一类是维护长期 SQLite 数据库的人。比如一个项目持续抓取数据，表结构会变，旧文件还要继续可用。对这类人，migrations 可能减少初始化脚本里的分支判断。
另一类是把 sqlite-utils 放进自动化链路的人。比如 CI 里生成 SQLite 文件，定时任务里更新数据库，再交给 Datasette 或其他流程发布。对这类人，nested transactions 的变化需要提前验证，因为事务行为一旦变了，失败回滚和异常处理都会受影响。
具体动作可以很朴素：不要直接升级生产依赖。先复制一份现有数据库和脚本，在测试环境跑完整链路。
重点看三件事：
- 旧的建表、补列、补索引逻辑，是否会和 migrations 的新流程冲突；
- 现有函数里如果已经开事务，放到外层事务下行为是否符合预期；
- 命令行输出、异常类型或退出码变化，是否会影响 CI 和定时任务。
这里不需要把事情拔高。候选版本的价值，就是让真正依赖它的人提前发现坑。不是让所有人抢着升级。
升级前要承认一个现实：现在还看不清全部兼容性
目前来源能确认的是：4.0rc1 已发布，新增 migrations 和 nested transactions，项目仍是 sqlite-utils 这个 Python 工具层。原文没有提供下载量变化、性能提升数据、企业采用案例，也没有说它改变了 SQLite 的底层能力。
所以判断要收着写。
SQLite 仍然是 SQLite。单文件数据库、写入并发等基本现实，不会因为 sqlite-utils 增加迁移和嵌套事务就消失。sqlite-utils 改善的是开发者操作 SQLite 的方式，不是 SQLite 本身的边界。
升级前最该看的变量也很具体：
| 观察点 | 为什么重要 | 如果不稳会怎样 |
|---|---|---|
| migrations 接口是否还会调整 | rc 阶段可能仍有变化 | 早写的迁移脚本可能要改 |
| nested transactions 文档是否清楚 | 事务问题最怕语义含糊 | 外层回滚、内层提交的预期容易错 |
| 3.x 到 4.0 的迁移说明是否完整 | 老用户最关心改动成本 | 自动化脚本可能在小差异上断掉 |
我更在意的不是 4.0rc1 本身，而是 sqlite-utils 是否能把这两项能力做得足够稳。迁移和事务都是“治乱”的工具。工具本身若不清楚，就会变成新的乱源。
如果正式版前接口、文档和兼容性说明都压实，sqlite-utils 4.0 会是小型数据工程里很实用的一步。若这些地方含糊，谨慎观望比追新版更划算。