Supabase Database Backup on the Free Tier⚡

Search for a command to run...

No comments yet. Be the first to comment.
Meta Description: Learn how to convert your Next.js website into an Android app using Capacitor on Windows. Step-by-step guide with Android Studio setup, APK generation, and deployment. If you've alre

This is Part 2 of my Next.js Caching series. In Part 1, we covered Browser Cache, CDN, Router Cache, Full Route Cache, Data Cache, unstable_cache, and use cache. Previously... We learned that a requ

When someone opens your website, does Next.js immediately query your database? Not always. A request may pass through multiple cache layers before your database is even touched. The more requests serv

Introduction If you've been building with React or Next.js, you've probably heard terms like: SSR SSG ISR CSR PPR React Server Components unstable_cache At first, they all sound like differen

While building My Project, one of the biggest challenges wasn't building the UI—it was deciding how to cache data correctly. I wanted my application to: ⚡ Feel instant while navigating 🔍 Remain SEO

Akash Blog
19 posts
On this page
Since automated backups aren't available on the Supabase Free Tier, I wanted a simple workflow I could run before every migration.
If you're on the Supabase Free Tier, these are the three most practical approaches:
The official Supabase method.
supabase db dump
Good for:
Official workflow
Exporting schema and data
CI/CD integrations
⚠️ Requires Docker.
The standard PostgreSQL backup tool.
pg_dump
Good for:
Quick backups before migrations
No Docker required
Fast restores
Works directly with Supabase
This is the method I personally use.
Want backups without remembering to create them?
Use GitHub Actions.
Benefits:
✅ Daily automated backups
✅ Backup history stored in Git
✅ No manual work
✅ Easy disaster recovery
I wrote a complete guide here:
👉 https://blog.akashy.com.np/automate-supabase-database-backups-using-github-actions
⚠️ Never store database backups in a public repository.
Install the Supabase CLI:
npm install supabase --save-dev
or
npm install -g supabase
Supabase CLI backup commands require Docker.
Download Docker Desktop:
👉 https://www.docker.com/products/docker-desktop/
Install and start Docker.
Verify:
docker --version
and
docker ps
Full dump:
supabase db dump \
--db-url "YOUR_DB_URL" \
-f backup.sql
Separate dumps:
supabase db dump \
--db-url "YOUR_DB_URL" \
--role-only \
-f roles.sql
supabase db dump \
--db-url "YOUR_DB_URL" \
-f schema.sql
supabase db dump \
--db-url "YOUR_DB_URL" \
--data-only \
--use-copy \
-f data.sql
This is my preferred approach.
No Docker.
No extra setup beyond PostgreSQL tools.
Verify installation:
pg_dump --version
Expected:
pg_dump (PostgreSQL) 17.x
Inside Supabase:
Settings
→ Database
→ Connection String
Use the Direct Connection endpoint:
postgresql://postgres:PASSWORD@db.xxxxx.supabase.co:5432/postgres
Basic backup:
pg_dump \
"postgresql://USER:PASSWORD@HOST:5432/postgres" \
> backup.sql
I prefer PostgreSQL's custom format:
pg_dump \
"postgresql://USER:PASSWORD@HOST:5432/postgres" \
--schema=public \
-F c \
-f backup.backup
--schema=public
Backs up only application tables.
Excludes Supabase-managed schemas like:
auth
storage
realtime
supabase_functions
-F c
Creates a compressed PostgreSQL backup.
Benefits:
Smaller file size
Faster restore
More reliable
Supports partial restores
Before every migration:
$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"
pg_dump `
"postgresql://USER:PASSWORD@HOST:5432/postgres" `
--schema=public `
-F c `
-f "backups\backup_$timestamp.backup"
Result:
backups/
├── backup_2026-06-23_10-15-20.backup
├── backup_2026-06-25_08-32-10.backup
├── backup_2026-06-27_14-41-55.backup
Now every migration has a rollback point.
Check contents:
pg_restore -l backup.backup
You should see your tables listed.
Example:
profiles
friends
notifications
movie_recommendations
If they're there, the backup is likely healthy.
Restore using:
pg_restore \
-d "postgresql://USER:PASSWORD@HOST:5432/postgres" \
backup.backup
⚠️ Always test restores on a development database first.
Never test your first restore on production.
More detailed guide onmy blog here - https://blog.akashy.com.np/restore-a-supabase-database-from-sql-backups-step-by-step-guide
Before running:
npx prisma migrate deploy
or
ALTER TABLE ...
I always:
✅ Create a backup
✅ Use timestamped filenames
✅ Verify using pg_restore -l
✅ Store backups outside my laptop
✅ Test restores occasionally
| Method | Best For |
|---|---|
| Supabase CLI | Official workflow |
| pg_dump | Fast manual backups |
| GitHub Actions | Automated daily backups |
My recommendation:
Before migrations → pg_dump
Daily protection → GitHub Actions
Restore testing → Local .backup files
That's the setup I currently use.
Backups feel unnecessary right up until the moment you need one.
If you're using the Supabase Free Tier:
Create backups before every migration.
Use timestamped backup files.
Store backups outside your machine.
Test your restores occasionally.
Automate backups when your project grows.
The entire process takes less than a minute and can save hours—or days—of recovery work later.
Happy building 🚀
Supabase Backup Documentation
https://supabase.com/docs/guides/platform/backups
Official CI/CD Backup Workflow
https://supabase.com/docs/guides/deployment/ci/backups
👉 https://blog.akashy.com.np/automate-supabase-database-backups-using-github-actions
👉 https://blog.akashy.com.np/restore-a-supabase-database-from-sql-backups-step-by-step-guide