Change your database safely

Your database's schema is its shape: which tables exist and which columns they have. Your live site depends on that shape at every moment, so Willo changes it in a particular order.

Add first, remove later

New things are added alongside old ones, never swapped in place:

A new column is added empty or with a default value, so existing rows and the live site keep working the instant it lands.
New tables, indexes and access rules don't disturb anything; Willo adds them freely.
Renaming is done in steps: add the new column, copy the data across, switch the site over to it, and only later remove the old one. Renaming in one go would break the live site the moment the database and the site's code disagree.

Removing things (dropping an old column, making a column required, tightening a type) comes later, after the site has run on the new shape and nothing reads the old one.

Deleting data needs your explicit yes

Deleting a table or a column, or narrowing a column's type, destroys data, and there is no undo for your business's data. Before doing it, Willo tells you in plain words what will be lost and waits for you to agree in the conversation. The change then also stops on a card.

Drafts change the timing

If your business is drafting, schema changes land on the draft backend and you can test them in the draft preview. At Publish, every one of them is replayed on your live database, in order, just before the new site goes live.

Two consequences:

A deletion hits live data at Publish, not when you made it. The draft started as a snapshot of live, but the replay acts on the live table as it is when you publish. Rows collected after the draft began are deleted too.
Add and remove in separate rounds. Willo won't bundle "add the new column" and "drop the old one" into the same draft. Publish the addition, check the site runs on it, then remove the old column in a later draft.

Rows written on the draft backend are test data. They are never copied to live.

Changes beyond the basics

Most changes go through Willo's step-by-step database tools, one statement at a time. Some don't fit: a database function, an automatic trigger, a migration that must succeed or fail as a whole, or SQL that your own AI agent wrote. Those run as SQL on an approval card that shows:

the statements, word for word,
a plain summary of what they do,
the tables and objects they touch,
any security findings, such as a table becoming readable by anyone.

A red finding is your call: Willo explains it rather than refusing for you. SQL has no undo, so the card is the moment to read it. Some things are refused outright, including changes to database roles and to Willo's own internal tables.

"Column not found" errors

If your site reports that a column can't be found, the site's code and the table disagree. Ask Willo to fix it: it reads the table's real columns and makes the code match, rather than adding a duplicate column. While drafting, a column you just added on the draft doesn't exist on live until you publish, so a live error about it is expected until then.