Database updates

When your app has a database, each deploy applies your new database updates (the files in backend/prisma/migrations/) before the new version goes live.

The safety check

Before anything touches your app's database, Ghosty first replays your entire update history on an empty rehearsal copy. Because your database's structure is exactly the result of that history, this catches broken updates before they can do any harm — for example an update that references a table no earlier update created, edited or deleted update files, or leftovers from an out-of-sync development database.

If the rehearsal fails, the deploy stops with a message like:

Your new database update 20260821_add_orders has an error and was not applied — nothing changed in your app's database. Fix the update and deploy again.

Nothing changed in your app's database — your app keeps running on the previous version, and no cleanup is needed. Fix the update (or delete and regenerate it), commit, and deploy again.

When an update fails against real data

Some failures can only surface against real data — for example, adding a required column to a table that already has rows without a value for it. If an update fails against your real database:

• Nothing is applied. The failed update is rolled back completely — your database is unchanged.
• The deploy fails with the real error. The deploy log shows which update failed and the exact database error, so you can fix the update in your code.
• You don't need to do anything else. Fix the update, commit, and deploy again. Ghosty automatically clears the failed state from the previous attempt — a failed update never blocks future deploys.

What to check when an update fails

• Does the update reference tables or columns that exist at that point in the history? Every update must build only on what earlier updates created. An update written against an out-of-sync development database is the most common cause.
• Was an older update file edited or deleted? The history must replay cleanly from the beginning.
• The deploy log (app → Deploys → the failed deploy) shows the full output, including the exact error line — written so you can hand it straight to your coding assistant.

If a deploy reports that Ghosty couldn't clear a previously failed update automatically, contact support — that state never resolves on its own.

Notes

• The safety check runs automatically on every deploy of a database app — there is nothing to enable.
• Apps created before this feature shipped deploy exactly as before; newly created apps get the check automatically.