Supabaseのプロジェクト上限を回避せよ。認証を自作した私が次世代DB「Neon」を選んだ理由

開発初期、Supabaseは最高の選択肢でした。ボタン一つでPostgreSQLが立ち上がり、GUIでデータを操作でき、APIも自動生成される。まさに魔法のような体験です。

しかし、開発が進み、複数のプロジェクトを抱えるようになると、壁に直面します。**「Supabaseの無料枠（2アクティブプロジェクトまで）」**という壁です。

ここからの選択肢は2つ。「既存の環境を壊して枠を空ける」か、「課金する」か。私がこの岐路で**サーバーレスPostgreSQL「Neon」を選んだ最大の理由は、「プロジェクト量産フェーズにおけるコスト構造」と「環境分離のリスク管理」**にありました。

今回は、バックエンド（FastAPI）で認証基盤をすでに自前で構築していた私が、SupabaseからNeonへ移行を決意した「金銭的・技術的」な理由を赤裸々に共有します。

SupabaseのProプランは月額$25から始まります。これ自体は企業利用なら安いものです。しかし、個人開発者が「実験的なアプリをたくさん作りたい（多産多死）」というフェーズに入ると、話が変わってきます。

Proプランにしても、プロジェクトが無制限に作れるわけではありません。2つ目以降（厳密にはコンピューティング枠を超えた分）は、プロジェクトを1つ追加するごとに約$10/月の追加料金がかかります。

「ちょっと新しいアイデアを試したい」「検証用のDBを立ち上げたい」と思うたびに、月額コストが積み上がっていく。まだ利益を生むかわからないテスト段階のプロジェクトに、固定費が比例して増えていく構造は、精神的にもお財布的にもかなり厳しいものがありました。

もちろん、コストをケチる方法はありました。「1つのSupabaseプロジェクトの中に、複数のスキーマ（app_A, app_B…）を切って同居させる」という方法です。

しかし、私はこれを却下しました。理由は**「テスト段階だからこそ、環境を完全に分けたかった」**からです。

「安く済ませるために、リスクをごちゃ混ぜにする」のはエンジニアとして避けたい。でも「分けるために課金し続ける」のも辛い。このジレンマに陥っていました。

そこで出会ったのがNeonです。私の抱えていた「コスト」と「分離」の悩みを、Neonは見事に解決してくれました。

スケーリングしても財布に優しい（サーバーレス） Neonはアクセスがない時に自動でスリープします。つまり、「使っていないテスト環境」にはお金がかかりません。 これにより、Supabaseのように「プロジェクトが存在するだけで課金」されるのではなく、実働分だけのコスト（または無料枠内）で、複数のプロジェクトを並行して維持できます。
「ブランチ」による完全な分離 NeonにはGitのような「ブランチ機能」があります。本番DBから一瞬でコピーを作成し、完全に独立したURL（接続先）が発行されます。これにより、**「コストをかけずに、論理的に完全に分離されたテスト環境」**を、コマンド一発で量産できるようになりました。これこそ私が求めていたものです。

SupabaseはBaaSとして「認証(Auth)」や「ストレージ」が強力ですが、私の構成は以下の通りでした。

もしSupabase Authに依存していたら移行は地獄でしたが、幸いにも私は**「ただのPostgreSQL」**としてしか使っていませんでした。そのため、移行作業はpg_dumpでデータを吸い出し、Neonに流し込み、FastAPIの環境変数（接続文字列）を書き換えるだけで完了しました。

誤解のないように言えば、Supabaseは素晴らしいサービスです。「認証からDBまで全部お任せ」で1つのアプリをしっかり育てるなら、Supabase一択でしょう。

しかし、私のように**「認証は自前で制御したい」「新しいプロジェクトを次々と立ち上げてテストしたい」**というフェーズにいる開発者にとって、プロジェクト単位の課金は重荷になります。

「必要なのは純粋なDBだけ」「環境は分けたいがコストは抑えたい」。そう考えるなら、Neonへの引越しは、開発ライフを劇的に快適にするベストな選択肢になるはずです。

まずは記事本文です。

ータストアを選択し直すことの重要性を痛感した移行劇でした。