The question covers three, and they do not have the same answer. A deletion made inside the application can be undone: nothing is really erased, the row goes to a trash from which a button restores it. Your data comes out whenever you want, every list having its own export. But a deployed application's database is backed up by NO automatic mechanism in the product — there is no backup command anywhere in the deployment chain, and it is the host's job to put one in place. Put plainly: one click too many fixes itself, a lost database does not. This page says exactly where the line runs, so you can ask the right questions before putting real data in.
Deleting, inside your application, destroys nothing
The Delete button does not delete: it marks the row as deleted through a dedicated column. It then disappears from lists, totals and indicators — but it is still in the database. A “Trash” card appears in Settings as soon as a row has been deleted, carrying a “Restore” button. This is checkable in the delivered code: none of the generated routes calls the database's permanent delete.
On top of that comes a two-step confirmation — a first click arms the deletion, a second confirms it — rather than the browser's confirmation dialog. So by far the most common case, the one click too many at the end of the day, is undone in thirty seconds and without calling anyone. It is also the only one of the three layers the application handles entirely on its own, which is why it comes first.
Getting your data out whenever you want
Every list carries a CSV export button. It exports the rows you SEE — filtered by the search box and the active filters — and the button's label carries the number of rows leaving: data you do not have on screen is never exported silently. The file is produced so that it opens correctly in a spreadsheet, without the row of broken accents that usually awaits exports.
It is a copy you hold, and it should be named for what it is: it is not a backup in the technical sense. A CSV does not restore an application — it carries neither the links between your tables, nor the history, nor what was deleted. It is there so you can take back control: open your figures in a spreadsheet, hand them to your accountant, feed another tool. It is what stops you being locked in, not what protects you from a failure.
What is NOT done, and what you have to settle
When your application is deployed, it gets its own PostgreSQL database. And nothing in the deployment chain backs it up: there is no backup command in the code that deploys applications. This is not an oversight being glossed over, it is a boundary — backing up depends on where the application runs, so it belongs to whoever hosts it, whether that is you, your provider, or us when we host it.
Three questions are enough to settle it, and they belong before you enter any real data. Who produces the copy, and how often? Where is it kept — somewhere other than the machine running the application, otherwise a single failure takes both? And above all: has anyone ever RESTORED from that copy? The third is the one people forget, and it is the only one that proves anything: a backup never restored is not a backup, it is an assumption.
What changes depending on what you put in it
Not everything deserves the same arrangement. For a tool whose contents can be rebuilt — a weekly schedule, light tracking you could retype in an hour — a monthly export filed somewhere is plenty. For a record that cannot be rebuilt, however — your members, the history of your service calls, your open case files — automated database backup is a prerequisite and not an option: nobody rewrites three years of history from memory.
The good news is that there is no technical obstacle: the generated code is standard Next.js and Prisma on a PostgreSQL database, with no proprietary format to work around, and backing up a PostgreSQL database is something any provider knows how to do. So the question is never “is it possible?” but “who does it, since when, and has anyone checked it once?”.