Functions and production

Observe, back up, and recover

Monitor database and platform signals, understand backup coverage, rehearse restore, check current limits, and keep provider-independent exports.

9 minute lesson

~~~

A production project you cannot observe or restore is a countdown. Set up both before the first real user, while mistakes are still free.

Watch what predicts trouble

Monitor errors, slow queries, connections, Auth failures, function logs, Storage failures, Realtime behavior, and usage limits. The dashboard’s Reports and Logs pages cover most of it; for query time, pg_stat_statements is already available:

select calls, round(mean_exec_time) as avg_ms, query
from pg_stat_statements
order by mean_exec_time desc
limit 5;

Tie alerts to user-visible outcomes. “Connections near the limit” and “Auth error rate climbing” deserve attention; a dashboard where every moving number alerts trains you to ignore all of it.

Know what a backup covers

Hosted projects on paid plans get scheduled database backups, with point-in-time recovery available when your acceptable data loss is minutes rather than a day. Read the current plan’s coverage and retention instead of assuming — limits change, and the moment to discover yours is not during an incident.

Database backups do not automatically mean every Storage object or external service is recoverable. Uploaded files live in object storage — the database only holds their metadata. If losing user uploads is unacceptable, keep exports or replication for those buckets too, wherever the recovery goal requires them.

Keep one provider-independent export in the rotation:

supabase db dump -f prod-2026-08-03.sql
# Dumping schemas from remote database...

That file restores into any PostgreSQL anywhere, which is the exit you hope never to need.

The drill is the proof

Restore a disposable backup or dump into a separate project — never over production. Then reconnect a copy of the application safely and verify the things that break quietly: Auth-linked ownership (do notes.user_id values still match users in the restored auth schema?), Storage files, and one complete workflow end to end, sign-in included.

The failure you are hunting: a restore that brings back your tables but not the auth data they reference, leaving every user_id pointing at nobody. Counts match, rows look fine, and no user can see their own data. Finding that in a drill costs an afternoon. Finding it in production costs you users.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →