# Supabase db reset is local by default—and destructive when linked

> Supabase db reset is safe for disposable local data. With --linked or --db-url it targets a remote database, so production needs a hard guardrail.

Source: https://saascode.ai/inside/supabase-reset-local · Published: 2026-08-21 · Section: academy

---
`supabase db reset` is a useful command precisely because it destroys state. That makes it a good local-development tool and a terrible command to discover inside a production deployment.

The default command targets the local Supabase stack. It recreates the local database, replays migrations, and runs the configured seed. Add `--linked` or `--db-url`, however, and the target can be remote. Supabase documents `db reset --linked` as destructive and suitable only for throwaway development or staging projects—not production.

In one mistaken remote reset, authentication state and the foreign-key chain below it had to be rebuilt. Recovery took more than 15 minutes. That small number understates the risk: on a database with real customer data and no tested restore, recovery may not be possible at all.

## Separate rebuild from deploy

A normal remote release applies pending migrations. It does not recreate the database:

```bash
supabase db push --dry-run
supabase db push
```

`db push --dry-run` gives you the pending migration list. Review that list, back up according to your recovery policy, then apply it to the intended project. Seed data belongs in an explicit environment-specific step; production should never inherit demo accounts or destructive seed behavior by accident.

A reset is legitimate when the environment itself is disposable. For example, a short-lived preview database can be rebuilt from migrations and seed data if the team has deliberately classified it that way. The command is still destructive; the environment policy is what makes the destruction acceptable.

## Make the wrong target hard to express

Do not rely on somebody noticing the current link in terminal output. Add structural controls:

- keep reset commands out of production deploy scripts and CI jobs;
- use distinct credentials and projects for local, preview, staging, and production;
- require an explicit environment name for destructive maintenance tasks;
- print and verify the target project before a remote database operation;
- deny destructive production jobs at the CI or platform permission layer;
- test restores, not only backups.

A simple wrapper can refuse production before invoking the CLI, but it should complement platform permissions rather than replace them.

## Audit the command with its flags

Search runbooks, package scripts, shell scripts, and workflow files for `db reset`. A bare `supabase db reset` belongs to a local loop. A use with `--linked` or `--db-url` needs an explicitly disposable target and a visible confirmation boundary.

The important distinction is no longer “this command is local only.” Current Supabase tooling supports remote reset on purpose. The publishable rule is sharper: reset means rebuild from zero, and production deployment is never a rebuild-from-zero operation.