sqlite-utils 4.0rc3: compound foreign keys ahead of the stable release

Simon Willison wanted to ship the stable release of sqlite-utils 4.0 this weekend. Instead, 5 July brought a third release candidate: sqlite-utils 4.0rc3. The reason, the author explains, is that the changelog since rc2 kept getting bigger while he worked through the backlog of issues and pull requests with the help of Claude Fable 5 and a second frontier coding assistant, as he explains on his blog.

For those unfamiliar with it, sqlite-utils is one of those quiet tools holding up half a data ecosystem: a Python library and a CLI for creating, transforming and querying SQLite databases, and the foundation of Datasette, Willison's own data publishing project. A major version bump here is not a formality: thousands of scripts, notebooks and pipelines have depended on its API for years. The 4.0 has been brewing across several release candidates, each one accumulating changes the author did not want to leave out of the stable release.

Compound foreign keys, the change that forced the wait

The headline feature in rc3 is support for introspecting and creating compound foreign keys, the ones referencing several columns at once. As Willison explains, the feature involves a subtle but breaking change to table.foreign_keys, the Python API that exposes a table's relationships. And that is the reason for the delay: a breaking change has to land before the final 4.0, because afterwards it would have to wait for a hypothetical 5.0. It is semantic versioning discipline applied with good judgement, and it explains why the author prefers one more release candidate over dragging the problem through the whole version 4 cycle.

Column names no longer case sensitive

The second significant change aligns the tool with a long standing SQLite convention: column names are case insensitive. It looked like a minor tweak and ended up touching, according to the changelog, a bunch of different places at once. It is the kind of cross cutting change that alone justifies an extra release candidate: easy to state, hard to scope.

How it is being done matters too

Beyond the features, the process itself is interesting. Willison has spent years documenting in public how he uses coding assistants, and here he describes, without drama, a dynamic that is becoming common in open source: a veteran maintainer clearing the backlog of a nearly decade old project with two frontier models working in parallel. The result is not unsupervised code, but more reviewed changes per release than a single person would tackle in a weekend. That this lengthens the release candidate cycle instead of shortening it says a lot about where the real bottleneck lies: in deciding and verifying, not in typing.

What to do if you depend on sqlite-utils

If you use the Python API, review any use of table.foreign_keys: it is the documented breaking change.
If your pipelines assume case sensitivity in column names, test rc3 now, before the new behaviour ships as stable.
* The GitHub release details the rest of the fixes accumulated since rc2.

Installing a release candidate in a test environment takes minutes and avoids surprises when the final 4.0 lands, which, given the project's pace, should be a matter of days or weeks.

At ElephantPink we follow projects like this closely because SQLite shows up in more corners of our deployments than we usually admit. A 4.0 that would rather be late than silently break its users' API is exactly the maintenance standard we would like to see more often.