Supabase入門｜Firebaseからの移行も
どうも、きこにいっす！ 株式会社終焉祝祭 代表取締役、そしてTikTokerのきこにい、31歳、既婚っす。
「終焉祝祭」って名前、ちょっと物騒に感じる人もいるかもしれないっすね。でもこれ、俺が経験してきたどん底から這い上がってきた道のりを象徴してるんすよ。
元々、年商1.6億まで駆け上がった会社が、一転して2億の負債を抱え、自己破産。うつ病で死んでた時期もあったんすけど、TikTok配信をきっかけに再起して、今じゃコミュニティ「アジト」も運営してる。
そんな俺が、今回話したいのは「Supabase」っす。
「え、きこにいってプログラマーだっけ？」って思ったそこのあなた！ 正解っす。俺はバリバリのエンジニア出身ってわけじゃないんすよ。でも、ビジネスを回していく上で、テクノロジーの知識はマジで必須だと痛感してる。特に、スタートアップや個人でサービスを立ち上げるなら、いかに効率よく、そしてスケーラブルに開発を進めるかが肝。
俺が最初にサービスを作った時なんて、正直、技術選定でめちゃくちゃ迷ったっす。Firebaseが流行ってるって聞いて、とりあえず使ってみたけど、「あれ、これって俺のやりたいこととちょっと違うかも…？」ってなることもあったんすよね。
そんな経験があるからこそ、今回は「Supabase」の魅力を、実際に使ってみた感想を交えながら、そして「Firebaseからの移行」という視点も踏まえて、熱く語っていきたいと思うっす。
Supabaseって何？ Firebaseと比較してみよう
まず、Supabaseが何かって話っすね。一言で言うと、「オープンソースのFirebase代替」って感じっす。
FirebaseはGoogleが提供してるBaaS（Backend as a Service）で、リアルタイムデータベース、認証、ストレージ、ホスティングとか、アプリ開発に必要なバックエンド機能が全部揃ってるのが魅力っすよね。俺も最初は「これさえあれば何でもできるじゃん！」って思ってたんすよ。
でも、Firebaseの弱点というか、俺が「うーん…」ってなった点もいくつかあったっす。
- NoSQLデータベース: FirebaseのFirestoreやRealtime DatabaseはNoSQLっすよね。柔軟性は高いんだけど、リレーションシップが複雑になったり、SQLに慣れてる人にとってはちょっと癖がある。俺も「あれ、このデータどうやって結合すんだ？」って頭を抱えたことが何度もあるっす。
- ベンダーロックイン: Googleのサービスにどっぷり浸かることになるんで、他のサービスに移行しようとすると結構大変。これはどんなクラウドサービスにも言えることだけど、オープンソースに慣れてる人からするとちょっと抵抗があるかもしれないっすね。
- 価格体系: 最初は無料枠で十分なんだけど、規模が大きくなってくると課金が跳ね上がるケースも。特にFirestoreの読み書き回数とか、予測しにくい部分もあるんすよ。「うわ、今月の請求額やべぇ！」って焦ったこともあったっす。
じゃあ、Supabaseはどうなのか？
Supabaseは、PostgreSQLをベースにしたBaaSっす。ここがFirebaseとの最大の違い。PostgreSQLはリレーショナルデータベースなんで、SQLに慣れてる人にはめちゃくちゃ使いやすいっす。俺もSQLは多少かじってたんで、Supabaseに触れた時は「これこれ！ この感覚だよ！」ってなったっすもん。
Supabaseが提供してる主な機能はこんな感じっす。
- PostgreSQLデータベース: これが肝っすね。PostgreSQLはめちゃくちゃ強力で、拡張性も高い。RDBに慣れてるエンジニアからしたら、Firebaseよりも断然とっつきやすいはずっす。
- 認証機能（Auth）: ユーザー登録、ログイン、ソーシャルログイン（Google, GitHubなど）が簡単に実装できるっす。俺のコミュニティ「アジト」の認証も、Supabaseで作ったらめちゃくちゃスムーズだったっす。
- ストレージ（Storage）: 画像や動画ファイルを保存できる。これもS3互換なんで、使い勝手がいいっすね。
- リアルタイム機能（Realtime）: データベースの変更をリアルタイムで検知して、クライアントに通知できる。チャットアプリとか作る時にめちゃくちゃ便利っす。
- Edge Functions: サーバーレス関数。FirebaseでいうところのCloud Functionsみたいなもんっすね。
- API自動生成: これがマジで神。データベースのテーブル定義をするだけで、RESTful APIとGraphQL APIを自動で生成してくれるんすよ。バックエンドの実装工数を大幅に削減できる。俺みたいな「早くサービス形にしたい！」ってタイプにはたまらない機能っすね。
なぜSupabaseに惹かれたのか？ 俺の経験から
俺がSupabaseに惹かれた一番の理由は、やっぱり「PostgreSQL」をベースにしてるってところっす。
自己破産して、うつ病で引きこもってた時期、マジで人生のどん底だったんすけど、その時に「もう一度何かを成し遂げたい」って強く思ったんすよ。そして、そのためには「自分でサービスを作れる力」が必要だと感じた。
独学でプログラミングを学び始めたんだけど、FirebaseのNoSQLには最後まで馴染めなかったっすね。なんとなく「データが散らばってる」感覚が拭えなくて、大規模なサービスになった時にちゃんと管理できるのか不安だった。
でも、SupabaseはSQLベースだから、データの構造をしっかり設計できる安心感がある。俺も「アジト」のユーザー管理とか、投稿機能とかを作る時に、Supabaseでテーブル設計をしたら、めちゃくちゃ直感的に理解できたっす。
あと、オープンソースっていうのもデカいっすね。コミュニティも活発だし、何か困ったことがあっても情報を見つけやすい。FirebaseだとGoogleのドキュメントがメインになるけど、Supabaseは世界中の開発者が支えてるって感じがするんすよ。
「終焉祝祭」という名前を掲げた俺の会社は、まさしく「終わりから始まる」を体現してる。だからこそ、どんな状況からでも、新しい技術を取り入れて、より良いものを生み出していく姿勢を大切にしたいんすよ。
Firebaseからの移行、実際どうなの？
「今Firebase使ってるんだけど、Supabaseに移行って現実的？」って思ってる人もいると思うっす。結論から言うと、「全然アリ！」っす。
もちろん、データベースの移行はそれなりに手間がかかるけど、不可能じゃない。特に、NoSQLからRDBへの移行なんで、データの正規化とか、テーブル設計の見直しは必要になるっすね。
俺が考える移行のステップはこんな感じっす。
- データのエクスポート: FirebaseからデータをJSON形式などでエクスポートする。
- Supabaseでのテーブル設計: エクスポートしたデータを元に、Supabase（PostgreSQL）で最適なテーブル構造を設計する。ここはちょっと頭を使うけど、将来的なスケーラビリティを考えるとマジで重要っす。
- データインポート: エクスポートしたデータをSupabaseにインポートする。SupabaseのCLIツールとかを使えば、ある程度自動化できるはずっす。
- 認証の移行: Firebase AuthenticationからSupabase Authへ移行する。ユーザーデータのエクスポート・インポートが必要になるっすね。
- ストレージの移行: Firebase StorageからSupabase Storageへファイルを移行する。
- API呼び出しの変更: アプリケーションコードでFirebaseのSDKを叩いてた部分を、SupabaseのSDKに置き換える。ここが一番コードの変更量が多いかもしれないっすね。
正直、一朝一夕でできるもんじゃないけど、長期的な視点で見ると、Supabaseへの移行はメリットが大きいと思うっす。特に、PostgreSQLの強力なクエリ機能とか、SQLの柔軟性を活かしたいなら、マジでおすすめっすね。
俺も最初は「データ移行とかめんどくせぇな…」って思ってたんすけど、一度やってみたら「あれ、意外とイケるじゃん！」ってなったっす。何よりも、移行後に得られる「これでガッツリ開発できる！」っていう安心感が半端ないっすね。
まとめ
Supabaseは、Firebaseの強力な代替になり得る、いや、場合によってはFirebaseを超えるポテンシャルを秘めたBaaSだと俺は思ってるっす。
特に、
- SQLに慣れてる人
- RDBの堅牢性や柔軟性を重視する人
- オープンソースの技術を好む人
- 将来的なベンダーロックインを避けたい人
には、マジで Supabase を試してみてほしいっす。
俺自身、自己破産というどん底から這い上がってきて、新しいことに挑戦し続ける中で、Supabaseのような新しい技術に出会えたことは、めちゃくちゃ刺激になってるっす。
昔の俺みたいに、技術選定で悩んでる人がいたら、ぜひ一度Supabaseのドキュメントを覗いてみてほしいっすね。もしかしたら、あなたのサービス開発の「終焉」を「祝祭」に変える、そんなきっかけになるかもしれないっすよ！
じゃ、今回はこの辺で！ またな！