Your Postgres database was not redeployed. Its most recent deployment is from 2026-09-13, and its volume is still attached. Redeploying your website does not touch the database's storage, so those rows were removed by a write made against the database itself, such as a command or migration your app runs.

We don't restore data after user-initiated changes like this. Our databases are unmanaged, so automatic snapshots, WAL recovery and point-in-time recovery aren't available to restore your data unless you've enabled them on the service.

To protect against this in the future, native volume backups and point-in-time recovery can be enabled on the Pro plan. With either one turned on, the database can restore itself after this kind of loss.

SO THERE IS NO WAY TO GET MY USERS BACK?? WHAT DO YOU MEAN? ARE YOU SURE??

We're sorry, we know losing those accounts is serious. We checked again: your Postgres service has one volume, it is still attached, and there is no second or detached copy of the data in the project, so there is nothing on it we can restore from.

We don't restore data removed by writes made against the database, so we can't bring those rows back. Your website runs python manage.py migrate as its pre-deploy command on every deploy, so that step, along with any other code that writes to the database, is where to look for what removed them. If you have a local database dump or another copy of that table, you can import it back into your Postgres service.

I DONT THINK I HAVE ANY OF THAT. MY USERS ARE JUST GONE?

We're sorry, we know this is a painful answer. We aren't able to restore rows deleted from your database, so unless a copy of that table exists somewhere outside the database, those 30 accounts can't be brought back from our side.

Your Postgres service itself is still running with its volume attached, so any new signups from here on will be stored as normal.

WHERE WOULD THAT POTENTIAL COPY BE

Your project has only one Postgres database and one environment, so the copy we mean would have to live outside it. The usual places are a local development database on your own computer (for example, if you ran the site locally with signups pointed at it), a database dump file you or a script exported at some point, or another database you copied the site's data into.

If none of those exist, those 30 accounts can't be recovered. The records most likely to still exist are outside any database, such as signup confirmation or welcome emails your site sent, which you could use to contact those users and ask them to sign up again.

IM SO CONFUSED WHY WOULD THIS HAPPEN

We understand the confusion. Redeploying your website doesn't wipe the database: your Postgres service wasn't redeployed and its volume stayed attached, so the data didn't disappear because of the deploy itself.

Rows only disappear when something connected to the database deletes them. Your website's code, its pre-deploy migration step, or a command someone ran against the database can all remove rows. The website's code and the migrations it ran during that deploy are where to look for what removed them.