Datasette 1.0a33 extends its ?_extra= API pattern to queries and rows

Simon Willison shipped Datasette 1.0a33 on 11th June 2026, another alpha in the long march toward a stable 1.0. The headline change is narrow but it closes a loop that has been open since 1.0a3: the ?_extra= query string pattern now works for queries and rows, not only for tables. The pattern also has documentation now, which for an API feature is arguably the more useful half of the announcement.

What's claimed

Datasette is an open source tool for exploring and publishing data. You point it at a SQLite database and it gives you a browsable web interface plus a JSON API for every table, row, and SQL query. The project has been in a 1.0 alpha cycle for years, with Willison using the alphas to settle the shape of the API before committing to backwards-compatibility guarantees that a 1.0 implies.

The ?_extra= mechanism is the thing being finished here. The idea is that the default JSON response should be lean, just the data, and anything else you might want, like column metadata, facet counts, the SQL that ran, or pagination details, should be opt-in through ?_extra= parameters. In 1.0a33 that opt-in model extends to the query and row endpoints, so the three main response types now behave consistently.

What's actually new

The substance is the consistency, not a new capability. Before this release, the extras system was a table-endpoint feature. If you were hitting a canned query or fetching a single row by primary key, you got whatever the endpoint decided to give you. Now the same ?_extra= keys apply across all three, which matters if you are writing a client that talks to Datasette generically rather than special-casing each endpoint type.

Why design it this way at all? The older Datasette JSON responses bundled a lot of context into every reply. That is convenient when you are poking at an API by hand and expensive when you are paginating through thousands of rows and recomputing facets you will never look at. The ?_extra= approach inverts the default: cheap responses unless you ask for more. For a tool whose whole pitch is publishing data at scale on cheap hosting, shaving the default payload is a real cost decision, not just tidiness.

Willison wrote up the details on the Datasette blog under the title "Datasette 1.0a33 with JSON extras in the API," and the Datasette documentation now describes the pattern rather than leaving it for people to reverse-engineer from release notes.

The build-it-with-LLMs footnote

There is a second thread worth flagging because of how casually it is presented. To demonstrate the new feature, Willison built a custom extras API explorer, and he did it by having Claude Fable 5 in Claude Code write the plan and GPT-5.5 in Codex Desktop do the implementation. His framing was that "API explorer tools are almost free to build now."

That line is the interesting claim, and it deserves a skeptical read. A throwaway explorer UI for an API you designed yourself is close to the ideal case for code generation: the spec is clear, the surface is small, the author can immediately tell whether the output is correct, and a bug costs nothing. "Almost free" holds for demo tooling built by the person who owns the API. It does not automatically generalize to production software where correctness is hard to eyeball and the cost of a subtle mistake is high. The split-model workflow, one model planning and another implementing, is a pattern more practitioners are reporting, but it is still early to call it a settled technique rather than one author's preference.

What changes for users

If you run Datasette, the practical effect is that you can write API clients against a uniform extras model and lean on documented behavior instead of observed behavior. If you do not run Datasette, the more durable signal is the design discipline: a maintainer spending an entire alpha cycle making JSON responses smaller and more predictable before locking in a 1.0, rather than piling on features. That is the unglamorous work that makes a 1.0 worth depending on.

The alpha label still matters. This is not the stable release, and the API can still move before 1.0 lands. Anyone building on Datasette's JSON output should track the alphas closely, because finishing the ?_extra= pattern across all endpoints is exactly the kind of change that signals the API shape is converging, which is usually when the remaining breaking changes get made.