Rowsafe vs pg_dump and cron
A nightly pg_dump on cron is free, simple and portable, but it can only take you back to the moment the dump ran, so a failure can cost up to a day of writes, and nothing checks that the dump restores. Rowsafe archives every change continuously, so you can restore to any second with up to about a minute of writes at risk, and it restores a full copy every week to prove it works. Keep pg_dump for portable exports; use WAL archiving, with Rowsafe or on your own, for recovery.
Checked on . Sources are listed at the end.
Rowsafe and a pg_dump cron job, side by side
| Feature | Rowsafe | pg_dump + cron |
|---|---|---|
| How it works | Continuous WAL archiving plus nightly full and differential backups with pgBackRest, scheduled and checked for you | A logical export of one database, run on a schedule by cron |
| Data you can lose | Up to about a minute of writes on a quiet database, less on a busy one | Everything since the last dump: up to 24 hours with a nightly job |
| Point-in-time recovery | Yes, to any second in the recovery window (about 1 to 2 weeks by default, adjustable), or to a Mark you saved by name | No. You restore to the moment a dump ran. The PostgreSQL docs note dumps can't be used for continuous archiving |
| Automatic restore tests | Yes, every week (Proof): a full restore on your server, started and checked database by database. Needs free disk of about 1.3 × the database size | No, unless you script and schedule one yourself |
| Backups in your own bucket | Yes: any S3-compatible bucket you own, such as Cloudflare R2, Amazon S3, Backblaze B2 or MinIO | Yes, wherever your script copies them |
| Client-side encryption | Yes: aes-256-cbc on your server before upload. The passphrase and bucket keys never leave it | Partial: only if your script encrypts the file (for example with gpg or age) before upload |
| Monitoring and alerts | Yes (Pulse): health score, disk forecast, slow queries, locks and WAL archiving. Alerts by email, Slack, Discord or webhook | No. You add failure alerts yourself, for example a heartbeat check that fires when the job doesn't report |
| AI-agent restore points (MCP) | Yes (Guard): an MCP server and a Claude Code hook save a Mark before risky changes | No |
| Portability | Physical backups: restore onto the same PostgreSQL major version | Yes: dumps can generally be loaded into newer PostgreSQL versions, and restored one table at a time |
| Open source | Yes: agent, CLI and installer are Apache-2.0, with signed releases and SLSA provenance. The hosted control plane is not open source | Yes: part of PostgreSQL |
| Setup | One command on the server, then one PostgreSQL restart when it suits you | A script and a cron line. No restart |
| Price | Free for 1 server, 3 databases. Pro $39/month (5 servers), Business $149/month (25 servers). Every plan has every feature. Storage is billed by your bucket provider | Free. You pay for storage and the time to maintain the script |
Which one should you use?
Choose Rowsafe if
- Losing up to a day of writes would hurt.
- You want to undo a mistake (a bad migration, a
DELETEwithoutWHERE) at the exact second before it happened. - You want proof that restores work without building the test yourself.
- AI coding agents run migrations or SQL against the database, and you want a restore point before each risky change.
- You want an alert when backups stop, instead of finding out during an outage.
Choose a pg_dump cron job if
- The database is small, changes rarely, and losing a day of writes is acceptable.
- You need a portable export: moving to another server, upgrading to a new PostgreSQL major version, or seeding staging.
- You want to back up or restore a single database, schema or table.
- You can't restart PostgreSQL or change its settings (WAL archiving needs
archive_mode, which needs one restart). - You run a database engine or operating system Rowsafe doesn't support yet.
The details
- Why a dump can't restore to a moment
pg_dumptakes a consistent snapshot of one database as of the moment it starts. Anything written after that exists only in the live database. Point-in-time recovery needs a physical base backup plus an unbroken archive of the write-ahead log (WAL), which PostgreSQL replays up to the moment you choose. That is what Rowsafe sets up, with pgBackRest.- What usually goes wrong with dump scripts
- The job stops running and nobody notices; the disk fills; roles and tablespaces are missing because they need
pg_dumpall; the file is copied to the same server it protects; or the dump has never been restored and fails when it matters. A scheduled restore test and a failure alert catch all of these. - Use both
- Dumps and WAL archiving do different jobs. A weekly
pg_dumpis a good portable copy for major-version upgrades and for pulling out a single table. Rowsafe covers everything in between, to the second. When you adopt Rowsafe, the adoption guide suggests keeping your old job running in parallel until Proof has passed a few times.
Questions
Is pg_dump a real backup?
Yes, a logical one: a consistent snapshot of one database at the time it started. It is a good portable copy. What it can't do is restore to a moment between dumps, so with a nightly job you can lose up to 24 hours of writes. Roles and tablespaces need pg_dumpall.
pg_dump cron or point-in-time recovery: which should I use?
If losing the writes since the last dump is acceptable, a dump on cron with an off-server copy, encryption and a failure alert is enough. If it isn't, use WAL archiving for point-in-time recovery: with pgBackRest, WAL-G or Barman on your own, or with Rowsafe, which sets up pgBackRest, keeps up to about a minute of writes at risk and tests a restore every week.
Can I restore a pg_dump to a point in time?
No. A dump restores to the moment it was taken. To go back to, say, 14:04 before a bad migration at 14:05, you need a physical backup and archived WAL.
Should I stop running pg_dump when I use Rowsafe?
Not right away. Run both until Proof, the weekly restore test, has passed a few times and you have practised one restore. Many teams keep a periodic dump for portability anyway.
Does Rowsafe restart PostgreSQL?
Turning on WAL archiving needs one restart. Rowsafe never restarts PostgreSQL on its own: you restart when it suits you, or confirm a restart on servers where you allowed it during install.
Sources
Facts about other products come from their own public pages, checked on . Products change: if something here is out of date, tell us at [email protected] and we will fix it.
Protect your first database today.
Free for one server and three databases. Upgrade when you add more.
Start free