Deleting data and what stays in backups
Deleted rows persist in backups until retention expires. What that means for a deletion request, and what happens when you delete a whole service.
Data you delete from your database persists in backups until its retention window expires. That is how backups work everywhere.
It is on a page of its own rather than in a footnote because it affects what you can truthfully promise your own users.
What that means for a deletion request
If someone asks you to erase their data and your retention is 30 days:
- Delete it from the live database. It is gone from anything anyone can query.
- It remains inside backup images for up to 30 more days.
- It leaves when those backups expire under the retention policy.
Access to backups is restricted and audited, and they are not queryable: a backup is a physical image, not a database somebody can search. Under GDPR this is generally handled by documenting the backup retention period and confirming that restored data is re-deleted. That is a question for your own data protection assessment, and our Privacy Policy and Data Processing Agreement are where the formal position lives.
If you need the window to be shorter, shorten the retention period. See retention.
Deleting a service
Deleting a service removes the running instance and its storage. Its backups are retained for the service's retention period and then expire.
Before deletion, you are offered an export. Take it. A pg_dump you did not need is cheap; a
restore you cannot perform is not. The offer stands right up to the moment the data is deleted, and
once the service is gone there is nothing left for us to dump.
See exporting.
Deleting an account
Two different things go by that name, and only one of them is on a schedule.
Asking us to erase you. There is no automated account-erasure mechanism. An account is erased by hand: you ask, and a member of staff works through the account's records. We answer within one month, and the Privacy Policy says when that can be extended. There is no self-service button and no schedule. Publishing a schedule we do not run would tell you your data was gone on a day when it was not.
Closing your last organisation. Ninety days after the last organisation you belong to is closed, a scheduled job overwrites the fields that identify you and keeps the record they were attached to. The Privacy Policy lists exactly what survives and why, and marks that period provisional: no retention period on this platform has been through legal review yet.
The audit trail is not erased on either path. It is append-only so that it cannot be quietly altered, which means an erasure does not reach it.
Service backups follow their own retention, which may outlast the account.
No lock-in, stated deliberately
pg_dump always works, on any plan, at any time. There is no proprietary storage format and no
proprietary protocol.
Data portability is a design property here rather than a retention concession.
What you will see
Deleting a service moves it to a pending-deletion state, and the Activity tab records the request. The service stops accepting connections. Its backups remain listed until the retention period expires.
Troubleshooting
You deleted rows and need them back. Restore to a point in time before the deletion, into a new service, and copy the rows across. See point-in-time recovery.
You deleted a service and need the data. If the retention period has not expired, the backups are still there.
Contact support any time by email or from your dashboard. Every service is monitored around the clock.
You need to prove deletion to your own customer. Delete from the live database, then state your backup retention period and that restored data is re-deleted. The period is the one on your service's Backups tab.