個人開発のバックエンドに Supabase を選んだ理由

個人開発では、バックエンドに Supabase を使うことが多いです。データベース・認証・ストレージなどがまとまって用意されているサービスで、ひとりで作るときに重宝しています。この記事では、実際に使ってみて「ここが効いた」と感じた点を、具体例つきで書いてみます。

「やりたいこと」がだいたい揃っている

個人でWebアプリを作ろうとすると、必要になるものはだいたい決まっています。

• データを保存する場所（データベース）
• ログインの仕組み（認証）
• 画像などの置き場所（ストレージ）

Supabase はこれらがひとまとめになっているので、サービスをあちこち組み合わせる手間が少ないのが助かります。中身は PostgreSQL なので、慣れた SQL でテーブルを作り、データを扱えるのも安心でした。別々のサービスを契約して連携させる、という個人開発で一番だるい部分が省けます。

認証が最初から使えるのが大きい

個人開発で地味に大変なのが、ログイン周りです。Supabase はメール認証や Google ログインが最初から用意されているので、ここを自前で作らずに済みます。クライアントからは、こんな数行でログインが書けます。

const { error } = await supabase.auth.signInWithOAuth({
  provider: 'google',
})

パスワードのハッシュ化やセッション管理といった、間違えると怖い部分を自前で持たなくていいのは、大きな安心材料でした。

RLS で「誰が何を見られるか」を守る

データベースに直接アクセスできる構成なので、行レベルセキュリティ（RLS） は最初に必ず設定します。たとえば「自分の解答履歴は自分しか見られない」を、こう書けます。

alter table answers enable row level security;

create policy "own rows only"
  on answers for select
  using (auth.uid() = user_id);

これをサボると、URLを叩けば他人のデータが見えてしまう、という事故につながります。Supabase を使うなら、RLS だけは最初に押さえておくべきポイントです。

向いている場面・気をつける場面

小〜中規模の個人プロジェクトには、とても相性が良いと感じています。一方で、無料枠には保存容量や同時接続数などの上限があり、しばらくアクセスがないとプロジェクトが一時停止する、といった挙動もあります。趣味のアプリなら問題になりにくいですが、本格運用するなら有料プランや上限の把握は必要です。

「まず動くものを早く作りたい」個人開発において、Supabase は心強い選択肢だと思っています。実際に マナビポータル も、この構成で作っています。