How long does a restore take?
Measured SupaHost restore times, how long a project is offline during a restore, what makes restores slower, and what happens to other projects on the instance.
Restoring a project on SupaHost usually takes minutes, and the project itself is offline for only part of that time. In a restore drill on a Pro instance (November 2026, same data every run):
| Database size | Total time | Project offline |
|---|---|---|
| 0.8 GB | about 4 minutes | about 55 seconds |
| 4.1 GB | about 12 minutes | about 4.5 minutes |
Other projects on the same instance stay online throughout.
What happens during a restore
You start a restore from Dashboard → your project → Backups: Restore
- Rebuild. SupaHost takes the base backup before your restore point and replays the database's change log (WAL) up to that point. This happens in a separate, temporary Postgres with no network. Your project is still online and serving traffic.
- Extract. It dumps just your project's database from that temporary copy.
- Swap. Your project's Auth, Data API and Storage are stopped. The live database is renamed out of the way and kept as a fallback.
- Load. The dump is loaded as the project's database, and the services start again.
Only steps 3 and 4 take the project offline. That's why a 4.1 GB database is offline for minutes, not for the whole restore.
What makes it slower
- Database size. The load in step 4 takes longer for bigger databases, especially ones with lots of indexes, since they're rebuilt as the data loads.
- The whole instance's size. Base backups cover the instance's whole Postgres server, so step 1 unpacks every project's data, not just the one you're restoring.
- How far the restore point is from the last base backup. Base backups are taken daily. A point late in the day means more change log to replay than one just after a backup.
- Write volume. A busy instance produces more change log to replay.
- Instance size. Larger plans have more CPU and memory for the rebuild and load.
On SupaHost
- You get an email when the restore finishes or fails.
- If anything fails, SupaHost puts the original database back, so a failed restore leaves you where you started.
- The database from before the restore is kept for 3 days, then dropped.
- A restore job times out after 6 hours.
- Storage files aren't rolled back. See A restore didn't bring back Storage files.
- Cron jobs keep running against the restored data. Pause jobs with side effects first: see Stopping cron jobs on a restored project or branch.
- Only the instance owner can start a restore.
Tips for a smoother restore
- Practise once on a test project with similar data, so you know the timing before you need it.
- Plan the offline window like a short deploy: show a maintenance message in your app, or pause background workers that write to the database.
- Take a fresh Create pg_dump export first if you want your own copy of the current state as well.