What happened?

Simon Willison announced on August 12, 2026 the alpha release of alchemy-utils 0.1a0, a database-agnostic version of his own sqlite-utils library. Willison described the project as a "morning shower project," saying he handed the task to Codex and the GPT-5.6 Sol Ultra model.

The task description asked for a library offering the same insert, upsert, insert_all, upsert_all, create, and update methods as sqlite-utils, along with table introspection features, but built on SQLAlchemy to run across multiple database engines. Willison noted that a handful of follow-up prompts brought the project to a state mature enough to publish as an alpha.

Why does it matter?

The project was built using red/green test-driven development (TDD) and pytest, referencing Willison's existing sqlite-utils and django-sql-dashboard repositories. The library was tested against PostgreSQL, SQLite, and DuckDB databases.

As an example, Willison showed that he could list the rows of a table from his blog's PostgreSQL database with a single uvx command. He also imported a CSV file listing trees in San Francisco into a DuckDB database with an automatically generated schema.

  • Because the library is built on SQLAlchemy, it supports multiple database engines, including PostgreSQL, SQLite, and DuckDB.
  • The initial CSV import took about an hour, but after optimization by Codex, that time dropped to 35 seconds.
  • The project was initialized with uv init and developed following the principle of committing early and often to a git repository.

What's next?

Willison noted that alchemy-utils is currently in alpha and signaled that he plans to keep developing the project. It remains unclear whether the library will eventually cover all core sqlite-utils features or whether support for additional database engines will be added.

The number that matters: working code versus usable code

The most-discussed part of the experiment was that the library appeared after a handful of prompts. But the most instructive figure is a different one: the first version worked correctly and did the same job in about an hour. After optimisation, 35 seconds. That is close to a hundredfold performance gap between the first output and a usable one — and it persisted in code that passed its tests.

This is an under-reported property of model-written code. Correctness is easy to check: tests either pass or they do not. Performance only surfaces when the code runs against real data at real size. What caught it in Willison's experiment was not a test but actually trying to import the San Francisco tree list.

What the experiment shows, and what it does not

The conditions were unusually favourable. Willison had designed the API being replicated himself; he could point the model at two of his own repositories as reference; he applied red/green test discipline from the start; and he had the expertise to judge whether the output was right. Someone without all four of those at once may not get the same result from the same process.

Some things are not shared either: there is no comparison against how long writing the library by hand would have taken, no defect count remaining in the alpha, and no data on what happens in production. Willison labels the release an alpha himself. This is not a productivity measurement but a single well-documented case — and much of its value comes from the prompt history being published in full.