Portable Backups for Managed Postgres with pg_dump and Plakar · Plakar | The Open Standard for Backup and Restore
Search...
Book a demo<br>Demo
Book a demo<br>Demo
Portable Backups for Managed Postgres with pg_dump and Plakar
Rishi Raj Jain
2274 words<br>July 17, 2026
11 min read
Edit this page on GitHub
You liked this article?
Share it
Join us
Help us
Rishi Raj Jain<br>Technical Author
TL;DR
Your managed provider keeps backups, but those backups live as a restore<br>button inside its console, and there is no way to download one. Plakar does<br>not replace pg_dump. It wraps it, turning your dumps into encrypted,<br>deduplicated snapshots that you can store externally and restore anywhere.<br>This post covers the setup, the storage pricing, and a restore drill that you<br>can run to test this in action.
The problem: you cannot download your provider’s backup
Usually, you would want a copy of your live Postgres database on your own<br>machine or on storage (like S3, R2, etc.) that you can control. You’d require<br>this when you want to run a migration against realistic data before it goes<br>anywhere near production, or you want to reproduce the bug that only shows up<br>with production data shapes. Also, you want to be sure that a bad afternoon at<br>your provider, or a billing lapse, or a decision to move to a different platform<br>next year, does not take your data with it.
Your provider might allow you to take backups on a schedule (or on demand) and<br>allow you to restore with a few clicks. While that is something that’s easier to<br>access and restore from, note that those backups are not copies you can hold,<br>move, or open anywhere else. The backup does exist, but it exists inside the<br>platform only (kind of a lock-in).
Supabase, for example, has backups that restore to the same project, in the same<br>region, through Supabase’s own infrastructure. Neon’s history window rewinds a<br>branch inside Neon. Amazon RDS snapshots live in your AWS account and restore to<br>a new RDS instance. In all three cases the backup does happen, but in all three<br>cases the backup is a state your provider can return you to rather than a file<br>you can use locally or directly access as you require.
If you cannot download it, you do not fully own it.
“My provider backs up Postgres” is true but still not enough
So there are two different jobs that both usually get called “backup”, and they<br>are solved by different tooling:
The first job is bringing your own project back to a recent state, quickly, on<br>the platform you are already paying for. Provider backups do this job well,<br>and you should keep using them.
The second job is everything else: Migrating off the platform, cloning<br>production into staging, handing a dataset to an auditor, or keeping history<br>that reaches back further than the provider’s retention window.
Retention windows on hosted Postgres platforms are shorter than you might<br>imagine:
Platform<br>Built-in retention<br>Longer history<br>Portable file you can download?
Supabase<br>Daily backups kept 7 days on Pro, 14 days on Team. Free projects get none<br>Point-in-time recovery add-on, from $100/mo per 7 days of window<br>No, restores happen in-platform
Neon<br>History window up to 7 days on Launch. Free tier is a 6 hour window<br>Up to 30 days on Scale<br>No portable copy
Xata<br>Managed backups with WAL-based point-in-time recovery capped at 35 days. The free tier gets support-assisted daily backups<br>No option today to go beyond 35 days<br>No self-serve download
Prisma Postgres<br>Daily snapshots kept 7 days on Starter and Pro, 30 days on Business, and taken only on days the database saw activity<br>No point-in-time recovery today, listed as future work<br>No self-serve download of a snapshot
Did you notice that none of these platforms hand you the backup it took for you?<br>Also, the retention column tells a similar story once you look at the ceilings.<br>Seven days is the common default, and the outer limit across all four is<br>somewhere between 30 and 40 days, usually on the plan that can get expensive<br>quickly. But if you were, say, running a 100 GB project and wanted to back it up<br>for 60 days, would it financially make sense to go with the priciest plan on any<br>of these platforms?
So why not just cron a pg_dump?
That is a fair question, and it does indeed work for taking a single backup at a<br>given instant, producing a full fresh copy of the database:
pg_dump "$DATABASE_URL" | gzip > backup-$(date +%F).sql.gz
Now, you can run that on a cron schedule and you have a portable copy of your<br>database every time it is ran but it does not manage those copies over time and<br>you simply end up with a directory of .sql.gz files named by date, with no index<br>and no quick way to know which of them will actually restore.
You might reach for compression to keep the size down, and it does help, though<br>only inside a single file. The catch is that gzip only ever looks at the one<br>dump it is compressing. It has no memory of the dump it...