目的はSupabaseのサーバーとローカルの差がない状態にします。

環境

Windows11
VSCode Powershell
Next.15
Supabaeサーバーとローカルで開発
Drizzle ORM

現在の状況

サーバー側でもGUIでテーブルをイジり、ローカル側でもテーブルを色々と弄って、カオスになった状態。

決断

必要なテーブル、ファンクション、不要なテーブル、ファンクションが入り乱れて、リセットしたくなったので。
DockerのVolumesからリセットをすると決めました。

※ローカルもサーバーもリセットしたいときであって、サーバー側のデータやスキーマを残したいときは参考になりません。

やり方

DockerのVolumesの削除
Next.jsのSupabaseフォルダの削除(ローカル側のスキーマ)
をしてから、
supabase init とローカルを0から作り、その他色々とコマンドを打って、ローカルとサーバーとの差分を無くします。

ローカル＜＝ Supabaseのローカル側開発環境のSupabase
サーバー＜＝ Supabaseのサーバー側開発環境のSupabase

記録、メモ

もしSupabaseのサーバーとローカルの差がひどくなって修復不能だと思ったら

supabase db resetで大抵の問題は解決すると思いますが、
GUIで色々いじっていると修復不能に陥る時があります。
そんなときは思いきってローカル側を０から再生成しています。

supabase initからやり直すのです。

Supabaseの初期化

初期化前の準備

サーバーとローカルのバックアップを取れるなら取っておきます。
この方法は各自好きな方法で行ってください。

ローカル側を完全に消して、
ローカルを新しく立ち上げて
サーバー側とのpullか差分diffをローカルに持ってきて同期させましょう。

※設定ファイル(config.toml)は別の場所に保存しておきます。
スキーマファイルは完全に同期した後に自由に使えばいいと思います。

DBはWebアプリには絶対必要で不可分だが、
Supabaseを外部ツールの一つと考え、気軽に再構築する

サーバーは作ってあるのを再利用します。
環境変数や、デプロイ先の設定をそのまま再利用できます。

やり直しのローカル
起動していたら停止させる
supabase stop

Docker の volumes を削除する
GUI Docker Desktopから削除

Supabaseのフォルダやファイルを消す
supabaseフォルダの削除

それぞれ再起動

再度初期化

supabase init

ローカルで起動させる時に
👇[analytics]をenabled = falseに設定する必要があります。

config.toml

...
[analytics]
enabled = false

# Supabaseの開始
supabase start
# ログイン
supabase login
# 指示通りにログインをする。(サーバーは作ってあるのを再利用する場合)

# 現在のNext.jsアプリとSupabaseを選ぶ。
supabase link
# プロジェクトを選択

# これでサーバーとローカルが繋がりました。現状を調べていきます。

supabase migration list

# サーバー側だけスキーマがあり、ローカルは新規作成したので空です。
   Local | Remote         | Time (UTC)
  -------|----------------|---------------------
         | 20250908204338 | 2025-09-08 20:43:38

#ローカル側に新しくマイグレーションファイルを作ります。
supabase migration new schema
supabase migration list

   Local          | Remote         | Time (UTC)
  ----------------|----------------|---------------------
                  | 20250908204338 | 2025-09-08 20:43:38
   20250909005536 |                | 2025-09-09 00:55:36

#サーバ側のスキーマを消します。
#(ココを残しておけばサーバーのスキーマやデータを残して置けると思います。たぶん)
supabase migration repair --status reverted 20250908204338

#ローカル側のスキーマファイルをサーバー側に適用します。
supabase migration repair --status applied 20250909005536

supabase migration list

   Local          | Remote         | Time (UTC)
  ----------------|----------------|---------------------
   20250909005536 | 20250909005536 | 2025-09-09 00:55:36

# supabase migration list はあくまでもローカル側から見た サーバーとローカルの同期の具合であることに注意してください。

# サーバーのスキーマをローカルに取り込み
supabase db pull
supabase migration list

supabase db push

Initialising cli_login_postgres role...
Connecting to remote database...
Remote database is up to date.

supabase db diff -f my_table ＜＜確認、差分がないかを調べる

# 20250909013050_my_table.sqlが出力されました
# 中身を見るとなにか書かれています。
# サーバーとローカルとの間に差があるということです。

# ローカルの状況をサーバーに知らせます。
supabase db push

Do you want to push these migrations to the remote database?
 • 20250909013050_my_table.sql

 [Y/n]
# Yを押します。

supabase db pull

Schema written to supabase\migrations\20250909013314_remote_schema.sql
Update remote migration history table? [Y/n] 

# Yを押します。
# 20250909013314_remote_schema.sql が作成されます。
# 中身を見てみます。

# この作成されたマイグレーションファイルの中身は空でした。
# これでマイグレーションファイルでも、実際のテーブルでも差分がないことが確認できました。
# 以上で作業は終了です。

# この後は Drizzle ORMなどで ローカルのSupabaseでNext.js 側のアプリ、スキーマを作成して、Trigger や Function も作成して、後でサーバーに反映していきます。
# 「サーバーのatuhスキーマ」には 直接ファイルから Triggerを設定できないので、 サーバー側のGUI(SQL Editor)から直接 Triggerのコードを書いて登録します。

db diffコマンド

supabase db diffコマンドの結果は、シャドウデータベース（マイグレーションを適用した理想状態）と現在のデータベースの状態を比較したものです。

ちょっとした疑問

Supabaseのサーバー側でテーブルをいじっても、ローカル側から見たらマイグレーションファイルのタイムスタンプが変わっていない、最新の状態なのか、古いマイグレーションファイルのままなのか不明なこと。

実際、サーバー側は最新の状態に 「反映されている」 が、ローカル側から見ると、マイグレーションファイルのタイムスタンプは変わらないし、新しいマイグレーションファイルも作られてないという状態だと思う。

これには、サーバー側のマイグレーションのタイムスタンプは1つだけだが、ローカル側のマイグレーションファイルは複数作れることに関係しているのだろう。

サーバー側が最新の状態だと判断できる安心するコマンドはないものか？
ローカルのSupabase CLIでサーバーのマイグレーションを新しい状態にする更新コマンドは無いのか？

※supabase migration listでは古いままで、サーバ側でいくらテーブルスキーマをいじっても古いまま。