Lesson 24 / 25
Backups, Limits, Cost and Lock-In
Operating a project over time.
Know your plan and your exit
Hosted projects get automated backups on paid plans, with point-in-time recovery as an add-on; free projects can be paused after inactivity. Database size, egress, storage, edge function invocations and realtime connections all have quotas or usage pricing, so set spend caps and alerts. Exact limits change over time: check the pricing page for your plan. Lock-in is lower than many backends because the data is standard Postgres you can export with pg_dump, and the stack is open source and self-hostable; auth users, storage files and edge functions still need a migration plan.
Taking your own logical backup
Using the CLI or standard Postgres tools.
# with the CLI against the linked project
supabase db dump -f schema.sql # schema only
supabase db dump --data-only -f data.sql # data
# or plain pg_dump with the connection string from the dashboard
pg_dump "$DATABASE_URL" --format=custom --file=backup.dump
# test restores regularly into a scratch database
pg_restore --dbname="$SCRATCH_DATABASE_URL" --no-owner backup.dumpA backup is only real after a restore test
Schedule periodic restores into a scratch project so you know the procedure and the time it takes before an incident.
Quick check: Why is Supabase lock-in lower than many proprietary backends?
- It has no pricing limits
- It stores data as JSON files
- Data lives in standard Postgres and the stack is open source
- Its API keys work on any provider
Answer
Data lives in standard Postgres and the stack is open source — pg_dump and self-hosting are exit options.