sqlite-utils 4.1 lets you insert rows with Python code

Simon Willison released version 4.1 of sqlite-utils on 11 July, barely four days after 4.0. It is a small dot-release, with no breaking changes, but it brings one concrete addition for anyone who uses the tool daily: you can now generate the rows to insert with Python code instead of always starting from a file.

sqlite-utils is Willison's library and CLI for creating and manipulating SQLite databases without writing SQL by hand. Plenty of people use it to build small pipelines, turn CSV into queryable tables or prepare datasets before exposing them to other tools.

What changed in 4.1

The `sqlite-utils insert` and `sqlite-utils upsert` commands now accept a `--code` option. With it you pass a block of Python code, or the path to a `.py` file, that defines a `rows()` function or a `rows` iterable with the rows to insert. It is a direct alternative to importing the data from JSON, CSV or TSV, which was the standard flow until this version. The option takes both inline code and an external file, depending on whether you prefer to keep everything in the command or reuse a script.

The point is that you no longer need to materialize an intermediate file when the data comes from a computation, an API call or an in-memory transformation. You write the Python that produces the rows and sqlite-utils takes care of putting them into the table. The change came through issue #684 and is listed in the release notes.

Why it fits the rest of the tool

It is not a new idea within the project. sqlite-utils already let you pass Python blocks as a CLI argument in other commands, for example in `convert`, which applies a function to the values of an existing column. The `--code` option extends that same logic to the insertion stage. The result is fewer temporary files and more direct scripting, something you notice above all when you chain commands in Bash or launch them from a cron.

Who it is for

The natural audience is anyone who already lives in the terminal: people who assemble quick ingestions, analysts who work with SQLite as a working format and developers who prefer a one-liner to a full script. If your data is already in a clean file, you will keep using the usual import; `--code` wins when the source is dynamic and building the intermediate file was pure busywork. A typical case is filling a test table with data generated on the fly, or dumping the result of walking a directory without first writing a CSV.

There is also an angle that is close to us. SQLite databases are a very common substrate for local data that ends up being queried by models and agents, whether through MCP or from a subagent that runs queries. Being able to build a table in a single command, from arbitrary Python, simplifies that upfront preparation stage that is almost never documented but is always there.

Context

4.0 shipped on 7 July and 4.1 barely four days later. That pace, small and frequent releases, is a hallmark of the Datasette and sqlite-utils ecosystem: each release solves one specific piece of friction instead of piling up big changes. Willison keeps the project open on GitHub and documents every option in the CLI reference.

At ClaudeWave we have been using sqlite-utils for a while to get datasets ready before wiring them into Claude workflows, and this kind of improvement fits that way of working. It is not a flashy change, but removing the intermediate file is one of those things you appreciate the third time you use it. Sometimes the good tool is the one that saves you a step you did not even know was unnecessary.