本物のデータベース。もうつながっています。

データベースが最初は空なのは意図的です。スキーマは、それを定義するリポジトリのものです。マイグレーションをビルドコマンドに入れておけば、デプロイのたびにスキーマも一緒に届きます。認証情報がどこにもコピーされることはありません。スキーマが同じデプロイで届くコードより遅れることもありません。

2026⁠年10月30⁠日から、Supabaseはpublicスキーマに新しく作ったテーブルへの権限を、アプリのページが使うロールに自動では与えなくなります。そのため、テーブルを作るマイグレーションで、そのテーブルへの権限を付ける必要があります。anonへのselectは、サインインしていない訪問者が読んでよいものだけに付けます。authenticatedにはselect, insert, update, deleteを付けます。サーバー側のコードがservice_roleを使うなら、同じ権限をそのロールにも付けます。ビューにはgrant selectが別に必要です。作成時にsecurity_invoker = trueを指定すれば、ビューの下にある行は、元のテーブルのアクセスルールで守られたままになります。

ビルドが実行するマイグレーションが失敗すると、ビルドも失敗し、前のバージョンはそのまま動き続けます。失敗するまでに適用されたSQL文は、取り消されません。

アプリの「データベース」ページに、Tofuがマイグレーションを適用すると書かれている場合、Tofuは更新のたびに、ビルドの前にsupabase/migrationsフォルダのファイルを適用します。1⁠つでも失敗すると、Tofuはその更新を、ビルドを始める前に止めます。すでに公開されているバージョンは、そのまま動き続けます。

構造は届く。データは届かない。ビルドが実行するマイグレーションは、このデータベースに反映されます。手元のマシンにしかない行は、マイグレーションが挿入しない限り反映されません。

Freeプランでは、アプリがTofuの共有静的ホスティング上にある場合、サイトのビルドでマイグレーションは実行されません。テーブルはビルドとは別に作成します。手順はアプリの「データベース」ページに表示されます。共有静的ホスティング上にないアプリなら、Freeプランでも、有料プランと同じくビルドでマイグレーションを実行できます。