Against Migration
Adding a field to a live system is, conventionally, a crisis. It demands a window, a script, a rollback plan — an entire bureaucracy erected around a single admission: that your data and your model have drifted apart, and one must now be dragged to meet the other. We added eight fields to a running application and convened none of it. The database was not consulted. It did not need to be.
The application in question is Kanban — one of two apps we build LastDB with, both running on LastDB. Its cards had been hoarding meaning in prose: which repository a task targets, whether it is blocked, how urgent. Prose is where structure goes to hide. We promoted those facts to fields. The procedure is unremarkable. Its cost is the entire point: there wasn’t one.
Schema belongs to the application
A conventional database treats the shape of your data as its own property — tables poured like concrete, altered only with permits. LastDB does not. The application declares the shape; the database stores facts against whatever shape it is given. The distinction is not academic. It relocates “add a field” from a database operation — scheduled, rehearsed, feared — to what it always should have been: a line in the app.
Ten fields became eighteen
The application declared the wider form — a superset. LastDB recognized it as the same object, larger, and expanded into it. The original ten fields go on addressing the data already on disk. The eight new ones are empty. Emptiness here is not absence; it is capacity — space the application may fill, or not.
No ALTER TABLE. No backfill. No window. Nothing to undo. The maintenance window — that scheduled apology — was never opened. We counted the cards before and after. Identical, to the row.
Evolving the model is therefore a property of shipping the application, not a project the database imposes on you, with its own runbook and its own held breath.
There was no cutover
Because the old form and the new are equally valid at once, there was nothing to cut over to. Two versions of the application addressed one body of data simultaneously, indifferent to one another — the old confined to its ten fields, the new fluent in all eighteen — without error, without ceremony.
An older writer simply omits the new fields; a newer one supplies them. The new structure accretes as the new version prevails. There is no half-migrated interval in which the system is brittle, because there is no migration to be halfway through.
The migration is a tax
It is not a technical necessity. It is a tax — levied by databases that confuse storing data with owning its shape, and paid by everyone downstream in windows, scripts, and dread. A one-line idea (“tasks should have a priority”) is conscripted into a deploy plan. Remove the confusion — let the application own the shape, let the database adapt, let both versions coexist — and the tax does not get cheaper. It ceases to exist. What remains is the only honest unit of change: the deploy.
Built with Brain and Kanban — open-source apps on LastDB — inside our autonomous build loop.