Availability and recovery for managed PostgreSQL on Voroa
What happens if your Voroa managed PostgreSQL database or its server fails: honest recovery times, backup schedules, data-loss windows, and how restores work.
This page explains plainly what protection your managed PostgreSQL database has, what happens when something fails, and how long recovery takes. We would rather tell you the honest numbers than promise “high availability” in fine print that does not hold up.
How your database runs
Each managed database runs as a single instance on one server, with its own reserved memory and an enforced storage limit. There is no hidden sharing of your database with other customers’ queries, and no second copy running in parallel.
There is no automatic failover. If the server your database runs on fails, your database is down until we recover it. Recovery is a deliberate, human-supervised process - we believe a careful restore beats an automatic system that can make a bad situation worse.
What protects your data
- Daily backups. Available on paid databases, and off until you switch them on in the Backups tab. Once on, the database is backed up every night to separate, durable storage in the same region. Backups are listed and restorable for 7 days. The stored copies themselves are removed within 30 days. You can also take a manual backup any time from the Backups tab, and download any backup. A database you have stopped yourself is not backed up while it is stopped — its existing backups are kept, and nightly backups resume when you start it.
- Every database in your instance. If you created more databases inside the same instance, each backup includes all of them, and a restore brings them all back. Users you created yourself with SQL are restored too, without their passwords, so set new ones after a restore. A backup download contains your main database only.
- Point-in-time recovery (paid databases, where enabled). With point-in-time recovery on, your database’s change log is copied to durable storage every few minutes continuously. This shrinks the maximum data-loss window from “since last night” to about 5 minutes. The Backups tab shows the exact range you can restore to, from the oldest kept snapshot to a few minutes ago, and warns you if recent changes are not being saved for recovery at that moment. How far back you can go depends on your workspace plan: 3 days on Free, 7 days on Growth and Scale. If your workspace moves to a plan with a shorter range, the longer range is kept for 7 more days before the shorter one applies.
Restoring to a point in time
When point-in-time recovery is on and self-serve restore is available, the Backups tab shows a Restore to a point in time button. If you do not see that button, open a support ticket with the minute you want and we run the restore for you.
The button opens a short three-step wizard:
- Restore point. Pick a minute inside the restorable range, in your local time. The most recent few minutes cannot be chosen, because they have not reached storage yet.
- New database. Name the new database (lowercase letters, numbers and hyphens, up to 30 characters). Its size, PostgreSQL version and database name are the same as the original’s.
- Review & pay. Pay for it like any new database. The restore creates a new database of the same size as the original, billed as its own database. Your original database is never changed.
After payment:
- Open the new database and press Restore now. Nothing is restored until you do.
- The page shows each step and a live log while your data is brought back, then the database becomes ready. Its connection details are new: get the password from its Connect tab.
- Check the data, then point your app at the new database. Delete whichever copy you no longer need.
Users you created yourself are copied without their passwords, so they cannot log in yet. They are listed
on the new database’s Users tab; give each one a new password with SQL as the main user
(ALTER ROLE name PASSWORD '...'), or create new users there, before your app uses them. If a restore does
not finish, it retries on its own; if it
still cannot finish, the database tells you so, and support will either complete it or refund the payment.
The honest numbers
| Scenario | Data loss (worst case) | Time to recover |
|---|---|---|
| You delete or corrupt data yourself | Since the last nightly backup - or about 5 minutes with point-in-time recovery | Under 1 hour from when you ask us (we restore to a new database) |
| Your database crashes but the server is healthy | None - it restarts in place automatically | Under 5 minutes, no action needed |
| The server fails and cannot come back | Since the last nightly backup - or about 5 minutes with point-in-time recovery | Several hours, and it starts when we find out |
Be aware of how a failure reaches us. We monitor the servers themselves - disk, capacity and the jobs that take your backups all alert us automatically. We do not currently have an automatic alert for a single database going down, and we do not run a 24x7 on-call rota. In practice that means the fastest way to start recovery is to tell us: open a support ticket, and treat the recovery times above as beginning from that moment rather than from the failure itself. We would rather write that down than let you assume a pager goes off.
What you can do
- Take a manual backup before risky changes (schema migrations, large deletes) from the Backups tab. It takes a minute and gives you a restore point you chose.
- Enable point-in-time recovery in your database’s Backups tab on paid databases where it is available, if minutes of data matter to your product.
- Keep your connection strings in environment variables, not hard-coded - if a restore lands on a new database, switching is one variable change.
What we deliberately do not offer yet
Automatic failover to a standby replica and read replicas are not offered today. If your workload cannot tolerate the recovery times above, tell us - real demand is what moves these up the list.