Skip to content
Rowsafe
Docs

What Rowsafe does for you

What runs by itself once your database is set up, what you do when something goes wrong, and what Rowsafe never does.

Once your database is set up (see the Quickstart), most of Rowsafe runs by itself. This page says what it does on its own, what you do on a bad day, and what it never does.

Every day, by itself

You don't have to do anything for these:

  • Every change is saved. Each change your database makes is copied to your storage bucket, at most about a minute behind. That is what lets you go back to any second. See Backups and point-in-time recovery.
  • Backups every night. A full backup on Sundays, and a smaller one (only what changed since) the other nights, at 01:00 UTC. Rowsafe keeps two full backups by default, so you can go back about two weeks. Old backups are removed for you.
  • Proof every week. On Sunday evening, Rowsafe restores your latest backup into a private scratch copy on your server, checks it, and deletes it. So you know a restore works before you need one. See Proof.
  • Pulse watches the database. Every minute the agent checks the database and the server: disk, connections, slow queries, cleanup, backups. You get a health score from 0 to 100, findings in plain words, and an Apply fix button for most of them. See Pulse.
  • Alerts when something needs you: backups failing, the agent offline, the disk filling up. Add an email, Slack, Discord or webhook channel under Settings, then Alerts and notifications. See notification channels.
  • "Your weekly Pulse" arrives by email every Monday: each database's health, the week's backups and Proof results, and the top things to fix. See Your weekly Pulse.

Everything is encrypted on your server before it leaves it, with a passphrase only you have.

When something goes wrong

These are the moments Rowsafe is for. In each one, you click; Rowsafe does the work.

You deleted rows by mistake

Say someone ran DELETE FROM customers without a WHERE at 3 a.m. Production keeps running while you fix it:

  1. Open the database, then Rewind → Find the moment. It shows the exact second of the big delete. Click Rewind to just before this. (Find the moment)
  2. Restore a copy of the database as it was then, next to production. (Restore a copy)
  3. Compare with production: Rowsafe counts, table by table, the rows that are missing now. (Compare)
  4. Bring back the missing rows. Rows written since stay as they are. (Bring back rows)

A bad UPDATE instead? The same steps, with Also restore rows that were changed.

An AI agent's migration broke the database

Say a coding agent ran a migration that dropped a column. With Guard set up, the agent saved a Mark (a named restore point) right before the migration, and told you its name.

  • To see or recover the data, restore a copy at that Mark: on the Marks page, click Restore a copy at this Mark, then compare and bring back rows.
  • Bringing back rows puts back missing rows. It can't bring back a dropped column or table. For that, rewind the whole database to the Mark. Everything written after the Mark is removed from the live database and kept aside for 7 days, so you can undo.

To catch this before it happens, preview the migration on a copy first.

The disk is filling up

Pulse forecasts when the disk will be full and warns you up to 14 days ahead. When the cause is something Rowsafe can clean up (an inactive replication slot holding old files, unused indexes, tables that need cleanup), the finding has an Apply fix button. When your data simply grew, you need a bigger disk: the forecast tells you how soon. See Disk forecast.

Backups stop working

For example, the keys to your bucket were changed. Rowsafe raises a critical alert within about 10 minutes, and the database stops counting as protected. The finding says what's wrong, and Check again tests it once you've fixed it.

The server dies

  • With a standby (a second server kept in sync): open Standby, then Promote. The standby becomes your database. You can also let Rowsafe fail over automatically; it is off by default.
  • Without one: your backups are safe in your bucket. You restore them onto a new server by hand, with pgBackRest, step by step: see Restore by hand. Practise it once before you need it.

What Rowsafe never does

  • It never sees your data. Backups are encrypted on your server. Your passphrase and bucket keys stay there. Rowsafe only stores names, sizes, settings and metrics. See the security model.
  • It never restarts or changes your database on its own. Only when an owner or admin clicks and confirms, and only what the server's root allowed when the agent was installed. The two exceptions are ones you turn on yourself: automatic minor updates and automatic failover.
  • AI agents can't change production. Through Guard, they can read health and backups, set Marks, preview migrations on a copy and make masked safe copies. They can't restore, rewind, restart PostgreSQL, apply fixes or promote a standby. A person does that.
  • It never runs commands or SQL sent over the network. The agent on your server runs only a fixed list of tasks.
Edit on GitHub