Datasette插件datasette-upload-dbs更新到0.5a0版本，新增了一套正式的HTTP API。开发者现在可以用一条带Bearer Token的curl命令，把本地构建好的SQLite数据库上传到托管实例，原子替换掉正在服务的旧版本。这个插件本身已经运行一段时间，上传和替换数据库的能力此前就有。
这次更新的价值不在于新增了数据库能力，而是把"构建完成到上线"这一步纳入自动化发布流程。适用前提没变：整库替换，不是在线增量写入。
datasette-upload-dbs 0.5a0：切换动作被正式API化
新增的接口路径是/-/upload-dbs。调用方式是一条curl POST：带上Authorization: Bearer $API_TOKEN，传db=@content.db文件和db_name=content参数。
上传流程分三步：文件先落地保存，再做校验，校验通过才会原子切换。/content这个路径从切换那一刻起，开始服务新版本数据库。
这套流程不新鲜，只是第一次被标准化成可以脚本调用的API，不用再手动登录服务器传文件。
它换的是发布流程，不是数据库能力
这套API解决的是发布问题，不是数据库读写问题。SQLite文件依然整体替换，不支持增量写入，也做不到Postgres、MySQL那种在线迁移。
这跟静态数据集的发布场景很搭。GitHub Actions里跑一次构建脚本，生成新的content.db，构建成功就调这条API，生产环境立刻切换到新库。
受益的是两类人：维护Datasette托管实例的开发者，和靠定期构建、发布SQLite静态数据集的数据团队。这类工作流以前得手动操作或自己写脚本调底层文件系统，现在有了官方支持的路径。
高频写入的场景不适合。数据库需要频繁在线更新、多用户并发写入，这套整库替换的思路帮不上忙，得继续用传统数据库方案。
最值得盯的限制：哪些细节还没交代
官方发布说明没提到文件大小上限、并发上传时的行为、切换失败后的回滚机制，也没说权限模型的细节。这些恰恰是生产环境最容易踩坑的地方。
| 已确认 | 未说明 |
|---|---|
版本号0.5a0，接口路径/-/upload-dbs | 文件大小上限 |
Bearer Token鉴权，db+db_name两个参数 | 并发上传处理方式 |
| 先保存、校验、再原子切换 | 切换失败的回滚机制 |
| GitHub Actions可作为触发场景 | 细粒度权限控制 |
想在生产环境接入这条API的团队，建议先在测试实例跑几轮：传大文件、故意传坏文件、并发调用两次接口，看看插件的实际表现。这几项目前只能自己验证，官方材料没给答案。
接下来最该盯的，是有没有人在正式环境跑出规模数据——比如上传几百MB的数据库，或者一分钟内触发多次切换会不会出问题。这类实测反馈，比版本号本身更能说明这套API能不能放心用在生产流水线里。