PR本記事にはプロモーション（アフィリエイトリンク）が含まれる場合があります。
CONTENTS目次
「新しいサイトを作るたびにSupabaseのプロジェクトを増やすべき？」——これは私が新規サイトを立ち上げるときに最初にぶつかった疑問です。結論から言うと、私は今回、プロジェクトを増やさず、既存のプロジェクトに新しいテーブルを同居させる構成を選びました。プログラミング未経験の会社員がAIを相棒に手探りでやってみた記録なので、正解の解説ではなく「一つの実例」として読んでもらえたらうれしいです。この記事では、なぜプロジェクトを増やさなかったのか、テーブルをどう分離したのか、そしてやってみて感じた注意点までを正直に書いていきます。
この記事でわかること
- Supabaseの1プロジェクトに複数サイト分のテーブルを同居させるとはどういうことか
- プレフィックスと番号付きマイグレーションでテーブルを分離した具体的な手順
- 使い回し構成の注意点と、向いていないケース
そもそもSupabaseの「1プロジェクト複数サイト」ってどういうこと？
Supabase（スパベース）は、データベースやログイン機能などをまとめて用意してくれるサービスです。私のようなコードを書かない人でも、ブラウザの管理画面からテーブル（データを入れる表のようなもの）を作れるのが助かります。
新しいサイトを作るとき、素直に考えると「サイトごとに新しいプロジェクトを1つずつ作る」という発想になります。プロジェクトを分ければデータも完全に別々になるので、いちばん分かりやすい方法です。
でも今回私が試したのは、その逆です。新規サイトのためにSupabaseプロジェクトを増やさず、すでにあるプロジェクトの中に新しいテーブルを追加する構成にしました。つまり1つのプロジェクトの中に、複数サイト分のデータが同居している状態です。
「Supabase 複数サイト」で調べると、プロジェクトを分ける派と同居させる派の両方が出てきます。どちらが正しいというより、規模や目的で変わる話だと感じました。私は個人事業レベルの小さなサイトを増やしていきたいので、今回は同居（使い回し）を選んでみた、というのが出発点です。
プロジェクトを増やさず、既存に同居させると決めた理由
プロジェクトをサイトごとに分ける方法にも良さはあります。データが物理的に完全に分かれるので、事故が起きても他サイトに影響しにくいのが最大の利点です。それでも私が「Supabase 使い回し」を選んだ理由は、いくつかあります。
- 管理する画面（ダッシュボード）が増えると、どれがどのサイトか分からなくなりそうだった
- 個人事業の小さなサイトが増える前提だと、プロジェクトが乱立して管理が重くなる
- 一括で状況を把握できたほうが、初心者の自分にはミスが少なそうだった
特に「管理対象が増える不安」は大きかったです。プログラミング未経験だと、設定項目が増えるほど何をどう触ったか分からなくなります。画面が1つにまとまっていれば、少なくとも見る場所は迷わないというのは、私にとって地味に大きなメリットでした。
💡 ポイント： プロジェクトを分けるか同居させるかは「事故のリスク」と「管理の手間」のトレードオフです。大規模になるほど分けるほうが安全で、小さく数を増やしたい段階では同居が扱いやすい、と私は理解しました。
ただし、これは「絶対にこっちが正解」という話ではありません。実際、後述するように同居ならではの怖さもあります。私は今の規模だと同居のほうが自分に合っていると判断した、というだけです。読者のみなさんの状況によっては、素直に分けたほうが安心できる場合もあると思います。
プレフィックスでテーブルを分離した実例
同居させると決めて最初に考えたのが、「どうやって既存サイトのデータと新サイトのデータを混ざらないようにするか」でした。1つのプロジェクトの中にテーブルがずらっと並ぶので、名前がバラバラだと、どれがどのサイトのものか一瞬で分からなくなります。
そこで採用したのが、テーブル名に固定のプレフィックス（接頭辞・名前の頭に付ける共通の文字）を付けるという方法です。新サイト用のテーブルには全部同じ頭文字のまとまりを付けて、既存テーブルと見た目で区別できるようにしました。
例えばイメージとしては、新サイト用のテーブルはすべて （サイト名）_◯◯ のような形にそろえる、という考え方です。こうしておくと、
- 管理画面でテーブル一覧を見たときに、新サイト分がまとまって並ぶ
- 「これは触っていいテーブルか」の判断が名前だけでつく
- 既存サイトのテーブルを間違って編集する事故を防ぎやすい
というメリットがありました。「1プロジェクト テーブル 分離」を実現する手段として、プレフィックスは初心者でも扱いやすい工夫だと感じます。特別な機能を使うわけではなく、命名ルールを自分で決めて守るだけだからです。
⚠️ 注意： プレフィックスはあくまで「見た目と運用ルールでの分離」です。データベースの仕組みとして厳密に隔離しているわけではないので、SQLを間違えれば他サイトのテーブルも触れてしまいます。名前で油断せず、実行するSQLは毎回どのテーブルを指しているか確認するようにしました。
マイグレーションSQLを番号順に手動実行した手順
テーブルを作るときは、SQL（データベースへの命令文）を書いて実行します。私はコードが書けないので、この部分はAIに手伝ってもらいながら進めました。
このとき意識したのが2つです。1つ目は、既存テーブルには一切触らない方針にしたこと。新サイトを足すのが目的なので、既存サイトのデータには手を出さない、と最初に決めておきました。同居構成でいちばん怖いのは既存への巻き添え事故なので、ここは強めのルールにしました。
2つ目は、マイグレーション（データベースの変更を段階的に適用していく作業）のSQLを番号順に分けて手動実行したことです。具体的には、0001 → 0002 → 0003 と番号を振ったファイルに分けて、順番に実行しました。
- 0001：ブログ本体用のテーブルを作る
- 0002：ストレージ（画像などのファイル置き場）まわりの用意をする
- 0003：アクセス解析用のテーブルを作る
この3本立てで新サイトの土台を組みました。ひとつのSQLに全部詰め込まず番号で分けたおかげで、
- どこまで進んだかが番号で分かる
- 途中でエラーが出ても、その番号だけ見直せばいい
- 後から順番を追って「何をやったか」を思い出せる
というのが初心者にはありがたかったです。「プレフィックス マイグレーション」という組み合わせで運用すると、テーブルの分離と変更履歴の管理がセットで整理できると感じました。手動実行なので手間はありますが、その分、自分が今何をしているかを一歩ずつ確認できる安心感がありました。
やってみて感じた注意点と、向いていない場合
実際に同居構成でやってみて、良かった点と同じくらい「気をつけないと危ない」と感じた点もありました。正直に書いておきます。
まず良かったのは、プロジェクトが増えないので管理する場所が1つで済むこと。そしてプレフィックスと番号付きマイグレーションのおかげで、新サイト分が既存とごちゃ混ぜにならず、追いかけやすかったことです。
一方で、注意が必要だと感じたのは次の点です。
- 1つのプロジェクトに全部乗っているので、設定を大きく変えると全サイトに影響しうる
- 名前での分離なので、SQLのミスが他サイトに波及する可能性がゼロではない
- サイトが増えるほどテーブル一覧が長くなり、プレフィックスの命名ルールが崩れると一気に分かりにくくなる
こうして並べると、同居構成は「ルールを自分で守れること」が前提なんだと実感します。逆に言うと、扱うサイトの規模が大きくなってきたり、他の人と共同で触るようになったら、素直にプロジェクトを分けたほうが安全だと思います。
私自身も「今の小さい規模だから同居で回せている」だけで、この判断がずっと正解とは限りません。今後サイトが増えて管理がつらくなってきたら、分ける方向に切り替えることも考えています。運営の方針については運営者紹介（/about）でも触れているので、よければのぞいてみてください。
まとめ
新規サイトのためにSupabaseのプロジェクトを増やさず、既存プロジェクトに新しいテーブルを同居させる構成を試した記録でした。ポイントは、テーブル名に固定のプレフィックスを付けて既存と分離したこと、既存テーブルには一切触らない方針にしたこと、そしてマイグレーションSQLを0001→0002→0003の番号順（ブログ本体・ストレージ・アクセス解析の3本）に分けて手動実行したことです。同居は管理場所が1つで済む一方、設定変更やSQLミスが全サイトに影響しうるリスクもあります。小さく数を増やしたい段階では扱いやすい構成ですが、規模が大きくなったら分ける判断も必要だと感じました。どちらが正解かは状況しだいなので、あくまで一つの実例として、みなさんの判断材料にしてもらえたら幸いです。
FAQ
よくある質問
QSupabaseの1プロジェクトに複数サイトのテーブルを入れても大丈夫ですか？
小さな個人事業レベルであれば、私は同居させて運用できています。ただし1つのプロジェクトに全サイトが乗るため、設定変更やSQLのミスが他サイトに影響しうる点は理解しておく必要があります。規模が大きくなったらプロジェクトを分けるほうが安全だと感じています。
Qテーブルの分離はどうやりましたか？
テーブル名に固定のプレフィックス（名前の頭に付ける共通の文字）を付けて、新サイト用のテーブルを既存と見分けられるようにしました。データベースの仕組みで隔離しているわけではなく、命名ルールでの分離なので、SQLを実行するときはどのテーブルを指しているか毎回確認するようにしています。
Qマイグレーションはどう進めましたか？
SQLを0001→0002→0003と番号順に分けて手動で実行しました。内訳はブログ本体・ストレージ・アクセス解析の3本です。番号で分けると、どこまで進んだかや、エラー箇所の見直しがしやすくなりました。
Q既存サイトのデータに影響は出ませんでしたか？
既存テーブルには一切触らない方針を最初に決めて進めたので、今のところ既存サイトへの影響は避けられています。ただし同居構成では巻き添え事故のリスクがゼロではないため、実行前の確認は欠かせないと感じました。