The Umami upgrade that fails ends the same way: the container boots, stops, and the log says A migration failed to apply. New migrations cannot be applied before the error is recovered from (Prisma P3018) or migrate found failed migrations in the target database (P3009). Seven GitHub issues between August 2022 and May 2025 are that message, on Postgres and on MariaDB, and the threads point to the same things to look at before you pull the new image. Five checks, each one you can start in a minute:
1. Do you already have a half-applied migration? A failed migration blocks every later one, so a database that has one will fail the next upgrade at once. In the database Umami uses:
SELECT migration_name, started_at, finished_at, rolled_back_at FROM _prisma_migrations WHERE finished_at IS NULL AND rolled_back_at IS NULL; Any row means a migration started, did not finish and was not rolled back. Fix that first (check 5), not after the upgrade.
2. Which database engine and version are you on? SELECT version();. Two causes are about the database, not Umami: Postgres 12 or older (#1604: the 1.39.0 and 1.39.1 migrations did not run there) and MariaDB (#2645 and #2693: 05_add_visit_id calls BIN_TO_UUID, which MariaDB does not have; reporters ran 10.4 to 11.2).
3. How big is website_event? SELECT COUNT(*) FROM website_event;. The threads that give a time give a rough scale: one commenter on Postgres reported several hours for about 1 GB of website_event on 05_add_visit_id and wrote a batch script, while the same thread has 1.5 GB in about 30 minutes and 1 GB in a few minutes (#2645); about 2 GB took about 15 minutes on a small machine and another user waited 15+ minutes for 09_update_hostname_region (#3408); about three years of data took roughly an hour (#3408); a 16-million-row website_event made 05_add_visit_id take "way longer than I expected" (#2206). Their hardware and versions differ, so read it as minutes to hours, not a formula.
4. Will something kill the container mid-migration? In #3408 a commenter suspected a healthcheck on the Umami HTTP heartbeat (5 s interval, 5 retries, no start period, so about 25 s): the server is not up until the migration ends, so the check cannot pass and the container may be marked failed and killed mid-migration. Another user with the same problem removed the healthchecks and wrote that it upgraded in about 5 minutes. For the upgrade run: remove or lengthen the healthcheck, and set restart: 'no' (a Swarm user in the same thread did) so nothing restarts the container halfway and leaves the state check 1 looks for. Then wait; do not restart it yourself.
5. Do you know the recovery before you need it? Back up first. Then, when a migration fails: read the migration name in the error (05_add_visit_id, 09_update_hostname_region) and look at its SQL. Finish the SQL by hand, then npx prisma migrate resolve --applied "<name>". Marking it applied on its own records it as done without running it, and a #2645 commenter then hit The column visit_id does not exist. If the migration never ran at all, --rolled-back is the other option (#1406).
The seven threads, and how each one closed
| Issue | Opened | Your upgrade path | What the thread shows | Closed |
|---|---|---|---|---|
| #1393 "Update script fails with new version of umami" | 2022-08-10 | Docker, to 1.37.0 | A comment says the 1.37.0 migration script was updated and to pull the latest image; the reporter confirms that fixed it, and the same comment lists the migrate resolve recovery. | 2022-08-12, completed |
| #1406 "Migration fails from 1.36.1 to 1.37.0" | 2022-08-10 | Postgres, 1.33.1 to 1.37.0 | Same release. The thread gives the recovery: yarn prisma migrate resolve --rolled-back "02_add_event_data", then migrate deploy. | 2022-08-16, completed |
#1604 "The column account.account_uuid does not exist in the current database after upgrading to 1.39.2" | 2022-10-26 | Docker, Postgres 12 or older, to 1.39.x | Maintainer: 1.39.0/1.39.1 migrations did not run on Postgres 12 and older; delete the 04_add_uuid row from _prisma_migrations and rebuild. Another user fixed it by re-running yarn update-db; a third wrote up moving to a newer Postgres by dump and restore. | 2022-12-07, completed |
| #2206 "[Docker] Upgrade from 2.4.1 to 2.5.0 fail" | 2023-08-18 | MySQL and Postgres, 2.4.1 to 2.5.0 | Still collecting comments in 2025: one user suspected the service timeout was reached before an index build finished, ran 03_metric_performance_index by hand and added its row to _prisma_migrations; the next, 05_add_visit_id, was then taking "way longer than I expected" on 16 million website_event rows (Postgres). | 2024-02-29, completed |
| #2645 "prisma migrate deploy Error: P3009" | 2024-04-04 | Fresh MySQL or MariaDB install | 05_add_visit_id calls BIN_TO_UUID, which MariaDB does not have (reporters ran MariaDB from 10.4 to 11.2). The title says P3009; the body shows P3018. Workaround in the thread: run a compatible version of the SQL by hand, then npx prisma migrate resolve --applied "05_add_visit_id". On Postgres, one reporter hit the same migration running several hours on a 1 GB website_event table and wrote a batch script. A comment in September 2025 says it is still an issue on MariaDB. | 2025-01-11, completed |
| #2693 "Migration error P3018 with MySQL migration 05" | 2024-04-18 | Docker, MariaDB 11.2.2 | The same 05_add_visit_id migration and the same FUNCTION umami.BIN_TO_UUID does not exist. Three commenters report npx prisma migrate resolve --applied "05_add_visit_id" got them running (one notes their tables were empty); another replaced the failing BIN_TO_UUID line and ran the migration by hand. A commenter on MariaDB 10.11.6 (no Docker) hit it too and notes that the #2645 author put P3009 in the title for a P3018 body, which is why they could not find that issue. | 2024-05-15, completed |
#3408 ERROR: "check-db" exited with 1 | 2025-05-09 | Docker, 2.17 to 2.18 | P3009 on 09_update_hostname_region. One user's walkthrough: with about three years of data the migration ran for around an hour, after about an hour with no success message in the logs the container was restarted, 09 then failed because its column already existed, and the migration had to be marked applied by editing its row. | 2025-08-09, closed as not planned (marked stale) |
Six of the seven closed as completed, the quickest within two days, the slowest after about nine months. The newest closed without a fix (marked stale). What they share: a migration stops half-way, the recovery is manual, and size or database engine decides who gets hit.
Where this comes from
Every row above links to the GitHub thread it came from. Six of the seven are one report on Umami's page, in its Self-hosting & upgrades area next to 5 other recent upgrade and hosting reports, which groups 29 recent reports from 87 public threads. What is stored and how to dispute a report: the data page. Upgrading soon? Watch Umami to get an email when a new report is added.
The number the threads leave open: they give migration times from about 5 minutes to several hours, but rarely a row count, a duration, the hardware and the version together. If you have run 05_add_visit_id or 09_update_hostname_region on Postgres, what were those four: your website_event row count, how long the migration took, your CPU, RAM and disk, and the Umami versions you went from and to? Reply with them; a handful of full answers would give a self-hoster a real number to plan a maintenance window around.
From Friction, by Grain64.
