はじめに

PlanetScale の無料枠が消え、 Supabase に移行して１ヶ月が経ったが、いまだに解決していない問題が存在している。それは、 Prisma と Supabase との間でどう言ったマイグレーションをするのがベストなのかという問題だ。これについていろいろな記事を探してみたが、答えに至ってるものはなかった。

概要

まず簡単にそれぞれにあるマイグレーション機能についてまとめたい。

Prismaのマイグレーション

Prisma では、まず schema.prisma というファイルを作り、そこにデータベースの情報を書き込み、それをもとにデータベースを構築する。schema.prisma に変更を加えるごとに prisma migrate dev を実行し、マイグレーションファイルを作成し、指定されたデータベースにマイグレーションを実行する。

特徴

• schema.prisma で美しくテーブルなどを定義できる。
• 自動でマイグレーションファイルが作成される。
• _prisma_migrations というテーブルが作成され、これで整合性チェックしている。
• prisma migrate deploy で今までのマイグレーションを適用できる。
• seed は JS で記述する。sql ファイルは使用できない。
• Supabase のローカルとリモートとのマイグレーションは別々。.env とかで URL をその都度変更する必要がある。

Supabaseのマイグレーション

Supabase では、ローカルで Supabase のサービスと全く同じ環境を立てることが出来る。supabase link をすることでリモートDBにもアクセスできるようになる。 supabase migrate new で新しくマイグレーションファイルを作成し、SQL を書き込んでマイグレーションを作成する。

特徴

• マイグレーションファイルは手動で、生の SQL を記述する必要がある。
• リモートでのマイグレーションの記録はデータベースではない他のところで記録する。（使ったことがない）
• マイグレーションファイルと seed.sql が supabase フォルダに存在していれば、ローカルで supabase db reset したときに自動的に初期化される（データも含む）。
• seed はファイルの拡張子の通り SQL で記述する。
• supabase db pull でリモートをローカルに反映し、 supabase migration up でローカルのマイグレーションをリモートに反映する（使ったことがない）

まとめ

できるだけ schema.prisma を元に自動でマイグレーションファイルを作成したい。

両方使う時の問題点

最初は Prisma でマイグレーションをしてそこで生成されたマイグレーションファイルの内容をコピーして Supabase でもマイグレーションファイルを作成し、リモートには Supabase のマイグレーションを使用していた。

メリット

• マイグレーションファイルの自動生成の恩恵を受けられる
• Prisma が使える
• ローカルで新しく環境を作るときに自動的にデータも含めて初期化できる。

問題点

• リモートでは Prisma のマイグレーション関連が使用できない。（_prisma_migrations テーブルが作成されない）
• 毎回コピーするのは美しくない。

今の手法

今は Supabase のマイグレーション機能は一切使わずに、ローカルもリモートも Prisma で管理している。

流れ

• schema.prisma の編集
• ローカルで prisma migrate dev
• .env をリモートに変更し prisma migrate deploy

問題点

ローカルで初期化時に、

• supabase db reset でリセット
• リセットが終わったら prisma migrate deploy でテーブルを反映
• 次に psql [dbUrl] < seed.sql で初期データ投入

というステップを踏む必要があり、Supabase の初期化機能が使えず、面倒。