Rollback ("down") Migrations

[itsmingjie]

Hi all! I've been using Hasura for my company's codebase but am interested in learning more about how Supabase works.

I'm trying to set up migrations, and after following the guide included in the Supabase CLI blog post, I was able to get a forward migration working. But I'm curious whether there is a way perform a migration "rollback"? Use case: developer A and developer B are working on two sibling branches, so when merging their branches it might be helpful to roll back applied migrations to resolve potential conflicts.

Hasura generates an up.sql and down.sql for each migration, and you can run hasura migrate apply --down 2 or hasura migrate apply --up 1 to move your database schema forward or backward in time. Is there a similar implementation that I'm missing for Supabase?

Hasura doc for rolling back migrations: https://hasura.io/docs/latest/migrations-metadata-seeds/manage-migrations/#roll-back-migrations

[oscyp]

Any update here?

[aripo99]

this is pretty important, how do others handle wrong migrations?

[glaksmono]

Anyone can give an advice?

[derjogi]

you can use

supabase migration repair --status reverted [your migration identifier]

to remove migrations from the migration table.
With that, you can: apply a new migration that un-does a previous migration, then remove both those entries with the repair --status reverted command from the migration table.

[otang]

Agreed. Would also like this.

[sjunepark]

This would be nice

[hnykda]

I would also love to have a nice solution to this. Currently, we do something like this, which is not ideal and sometimes breaks:

git checkout commit-to-which-to-revert

supabase db reset

# generate diff - this "drops" the changes
supabase db diff -f revert-latests.sql

# manually execute the revert-latests.sql 

# get the migrations table
supabase migration list

# mark the migrations you don't want to be applied as reverted
supabase migration repair --status reverted ...

[Rajat-Nipane]

Are you doing this manually or you wrote all this steps in CI/Cd pipeline. I am trying to do similar thing.

[jankalfus]

[hnykda]

I disagree with you. Your advice might be good for a mid-size+ org with many users, valuable data, etc. A small start-up following this advice with a couple of design partners with a couple of devs will get slowed down totally unnecessarily (simply because losing data since the last migration is totally acceptable, compared to always having to dump everything, validating ad-hoc backups, paying for PITR, ...).

Case in point, e.g. django does have this feature for years, many teams use that extensively without any problems.

It's totally valid supabase doesn't have this, there might not care about these customers/not worth it, I respect that. But I am wary about saying "this is how it's supposed to be done in this case, therefore it applies in general, therefore you should not ask for/use this feature". Let me handle my risk analysis on my own, feel free not to use the feature, but don't tell me I shouldn't need it based on generalization from an example that is not everyone 😁 .

[aripo99]

totally disagree with this point. doing a database backup before executing each migration is unnecessary work. most migrations are easily reversible, and there's a reason why so many frameworks support rollback. also in terms of developer experience being able to rollback is super nice (right now my solution in supabase is to reset the db, which is a pain)

[jankalfus]

To clarify, I was just saying what’s considered best practice (i.e. what’s a safe default), since the original question was how do you perform a migration rollback. And I was guessing that this might be the reason, or rather one of the reasons, supabase doesn’t support it.

Nobody says you need to do it that way, that’s a misunderstanding, do it whatever way you want to, especially if you’re fine with losing data.

[danielwei15]

Bumping this -- automatic down migrations would be incredibly helpful within many developer workflows.

[danielwei15]

Especially now, with Supabase branching and migrations becoming an essential part of the new Supabase experience. Otherwise, as it stands, it seems there's no good way to "undo" Supabase branch merges either.

[sweatybridge]

I agree with this assessment that we need to revisit this to "undo" branch merges, ie. reverting a commit that contains migrations changes. Our plan here is to build on top of declarative schema so that down migrations can be generated automatically.

The current workaround is to add a new migration file to the revert PR with manually written statements to "undo" anything you wanted to revert.

[johnconnorquigley]

bumping this ^

[guilhemheinrich]

bumping this ^

[kallebysantos]

Hi, I'd create a simple shell script to handle it for me.
It's pretty simple to use.

Adding new migration

./supabase-migration new "documents entity"
This command will create a new migration files, both up and drop.

Applying migration

./supabase-migration up
This command will do the samething as the default supabase-cli migration up

Rollback migration

./supabase-migration rollback
This will look into migration history, then it tries to execute the drop script of the last migration. You could customize the $limit var to rollback recursively.

Code

The script will tries to look into you .env files to get a connection string.
So you may need to include it: PG_CONN_URL=postgresql://postgres:$POSTGRES_PASSWORD@$DEFAULT_HOST:$POSTGRES_PORT/$POSTGRES_DB

NOTE: I'd use Fuzzy Finder to help find the correctly drop script

#!/bin/bash

set -a # automatically export all variables
. <(cat .env supabase/.env)
set +a

# Function to display help information
help() {
	echo "Usage: $0 [command] [options]"
	echo
	echo "Commands:"
	echo "  new NAME   Create a new migration item"
	echo "  up         Push the current state"
	echo "  rollback   Rollback to the previous state"
	echo "  help       Display this help message"
	echo
	echo "Options for 'new' command:"
	echo "  -n NAME    Specify the name of the new migration"
}

new() {
	local migration_name=$1
	shift
	local migrations_folder="./supabase/migrations"
	local migration_timestamp="$(date +%Y%m%d%H%M%S)"

	mkdir -p $migrations_folder

	echo "-- $migration_name | Up commands" >"$migrations_folder/${migration_timestamp}_$migration_name.sql"
	echo "-- $migration_name | Drop commands" >"$migrations_folder/${migration_timestamp}|_$migration_name.drop.sql"

	echo "Created $migration_name migration files"
}

rollback() {
	read -p "Attention the Supabase DB will be rollback to the previous migration. Are you sure? (y/N) " -n 1 -r
	echo
	if [[ ! $REPLY =~ ^[Yy]$ ]]; then
		echo "Operation aborted"
		exit 0
	fi

	local rollback_limit=1

	read -red '' -a versions <<<$(psql $PG_CONN_URL -t -A -c \
		"select version from supabase_migrations.schema_migrations order by version DESC LIMIT $rollback_limit;")

	for version in "${versions[@]}"; do
		local drop_file=$(fzf --exit-0 --select-1 -q "$version|_.drop.sql")
		if [[ -z $drop_file ]]; then
			echo "No drop script found for $version migration."
			exit 1
		fi

		echo "Rollback migration: $version with '$drop_file'"
		local drop_result=$(
			psql $PG_CONN_URL -t -A --single-transaction -f \
				<(cat <(echo "delete from supabase_migrations.schema_migrations where version='$version';") $drop_file)
		)

		if [[ $drop_result == *"ERROR"* ]]; then
			echo "==="
			echo "Error while executing script: '$drop_file'"
			exit 1
		fi

		echo "Rollback migration: Successfully executed '$drop_file'"
	done
}

main() {
	local command=$1
	shift

	case $command in
	new) new "$@" ;;
	up) ./supabase-cli migration up --self-hosted $@ ;; # Here you can put the default supabase-cli
	rollback) rollback ;;
	-h | --help) help ;;
	*)
		echo "Invalid option: '$command'"
		help
		exit 1
		;;
	esac
}

main "$@"

There is another alias script supabase-cli that I made to simplify the --db-url command for self-hosted projects.

#! /bin/bash

set -a # automatically export all variables
. <(cat .env supabase/.env)
set +a

ARGS=$*

# '--self-host' : Use Self host
if [[ $* == *"--self-host"* ]]; then
	ARGS="$@ --db-url $PG_CONN_URL"
fi

# echo $ARGS

pnpm dlx supabase $(echo ${ARGS/--self-host/})

[eqoram]

I was quite surprised when I found this discussion! Should be one of the essentials to also be able to undo migrations.

[GitTorres]

How is this not a thing? Please add rollback for last migration.

[ccarstens]

+1 for needing down migrations!

[qhkm]

+2 for rollback migration

[HowieG]

+1

[terryds]

+1

[dbj]

supabase df diff unfortunately does not catch everything you may do via the UI and/or the SQL console. If I do anything in the UI or SQL console, I immediately follow up by adding it to a migration so I don't lose track of what changes were made.

Regarding not having down migrations for a production deploy, after reading the docs, I believe the general recommendation is do enough testing you are sure you will not have to roll back production after pushing the migrations, or, as an alternative, having a migration written ahead of time that is essentially a down migration that you can quickly push up if necessary.

Not the best solution; it would be much better to have formal down migrations so you don't mess up the migration history will rollbacks, and can write them and not worry about accidentally pushing the wrong migration.

In development, my team and I use supbabase db reset with some good seed.sql files. It really is a better cycle for us rather than relying on down migrations. In staging, jury is still out if supabase db reset is as convenient and useful as for development.

[stgoerlitz]

+1

[derjogi]

Long story short: you can use

supabase migration repair --status reverted [your migration identifier]

if you just want to remove a migration entry from the database.

(Or probably best: Apply a new migration that un-does a previous migration, then remove both those entries with the repair --status reverted command from the migration db)

Details:

I recently started using AI with MCP, and in my last session I asked it to add a new RLS Policy.
AI went ahead and did that, but on the remote with the apply_migration MCP command.

That was not what I wanted, but well, I did actually need the RLS, and there was no error in it or anything, so I thought let's just go with it.

Stupid thing is that the naming scheme the AI applied to the migration was also different than mine; which breaks the ordering.
So normally I could have just created a migration file with the same name locally, apply it locally, and everything should sync up nicely, but due to the naming scheme I couldn't.

In this case, I HAVE TO revert, there's almost no way around (I could have from now on adapted a new naming scheme, but I don't want to!)

Took me a while to find out that supabase migration repair --status reverted [my migration number] does the trick to remove the migration schema from the database; and then I can just manually remove the new RLS policy.

I'm surprised though that this command is only mentioned once as part of another script...

And I would say that a situation like this is a good and valid example of why sometimes rollback is really helpful (yes, of course we should always check what AI does, and we should always test things before it goes to prod etc...) But sometimes sh*t like this happens and you just want to revert!

[terryds]

We eventually decided to use node-pg-migrate for migrations, it supports migrate down as well https://salsita.github.io/node-pg-migrate/ We can use it with Supabase

…

On Wed, Apr 23, 2025, 12:26 Jonas ***@***.***> wrote: you can use supabase migration repair --status reverted [your migration identifier] to remove migrations from the migration table. With that, you can: apply a new migration that un-does a previous migration, then remove both those entries with the repair --status reverted command from the migration table. — Reply to this email directly, view it on GitHub <#11263 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYJBQ4SB6OHBS3XUWRTVQL224QBRAVCNFSM6AAAAAATJG6YDKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJRHAZDAOI> . You are receiving this because you commented.Message ID: ***@***.***>

[vishalvibes]

Super duper needed

[eqoram]

Looks like there is something in the pipeline for this: supabase/cli#3635

[dangbert]

As far as I can tell this doesn't support a system for rolling back a single migration in a "safe" way that minimizes data loss on production (as would alembic for example).
But rather is the same as npx supabase db reset followed by applying your migrations (and seed.sql) up until a desired migration (so supporting early stopping while stepping through the migrations).

For Supabase to support truly support rolling back a single migration (even on production), I believe they'd have to support users maintaining a separate set of rollback .sql scripts which undo each respective migration in the desired way. The downgrade() function in an alembic migration is a good example of this.

(It's possible I've been interpreting the idea of a "rollback" different than others in this PR)

[rome2o]

+1.

It's no brainer and much needed. We'd stop rolling Laravel or Django and embrace Supabase even more. You embrace developers community, they embrace you.

[abdelhak-ajbouni]

a better migration cli and support for db transactions would make supabase perfect

[therealpurplemana]

dbmate does this nicely for postgres but why not supabase

[wkirby]

Hilarious that this is 3 years old.

[yousufnoor5]

It's 2025, still no rollback option :(

[vishalvibes]

Need this

[pedrogiroldo]

+1

[PHEXCEL]

+1

[rocxteady]

+1