FirebaseとSupabase FlutterFlowでどっちを使うか問題 2023年版
FlutterFlowを最近使い始めた人によく聞かれる質問なので、ここで改めてプロコンを比較して個人的な推しをお伝えできればと思います。
結論：いろいろ考えたらSupabaseいいよね
はい、結論から言ってしまいました。
ご存知の通り FlutterflowではSupabaseがFirebaseと共に公式サポートされており、プラットフォーム上で統合されています。
どちらも同じBaaS（Backend as a Service）であり、Fireabaseは特にモバイルに特化しているのでmBaaS（mはmobileのM）と言われたりもしています。
なので、この記事では同じBaaSである両者をFlutterFlowを活用する前提で基本的に知っておくべき共通点と違いを比較していきたいと思います。
基本情報
Firebase：2011年創業
Supabase：2020年創業
そもそもSupabase自体がFirebaseの利便性は認めつつも、SQLサーバーの方がデータ分析するにも何するにも便利だし、なによりオープンソースだしいいよねというところから、Firebaseの代替サービスを作る目的で始まっていますのでSupabaseの創業がFirebaseより後なのはあたりまえですね。
なので、利便性に関しては9年も先に事業を開始しているFirebaseにあることは明らかであり、比較するのは酷な気もします。
ただし、Supabaseの機能追加に関するスピードはかなり早い印象で、2022年にはシリーズBで100億円近い資金調達もしているので今後も速いテンポで便利機能がどんどんリリースされてくるという期待ができます。
参考：Supabase raises $80M Series B for its open source Firebase alternative
比較①：価格
どちらも最初は無料で始めることができるところは一緒。ただし、従量課金の課金形態に根本的な違いがあり、サービスがスケールするにあたりそのインパクトは無視できない請求額となると考えられます。
Firebase
- 無料でユーザー数は無制限に追加できる
- カスタム関数は従量課金のため無料では使えない
- データベースのReadとWriteのタイミングで毎回課金される
Supabase
- 50,000アクティブユーザーまで無料
- 従量課金は基本的にデータの通信料と保存しているデータ容量のみ
Firebaseの無料プランで提供されない唯一のものは、クラウド機能です。ここれはひとつSupabaseとの違いになっていて、Supabaseでは定額の中に含まれています。
ですが、料金設定でなによりも大きい違いは、従量課金の対象であり、Firebaseを使用している場合はデータベースのREAD / WRITE つまり、読み取りと書き込みのたびに料金が発生します。（SupabaseはAPIリスエストは無制限）
読み取りと書き込みはアプリによってどの程度の頻度で発生するかは異なりますが、基本的に初期の段階では非常に予測不可能な項目であるため、アプリによっては突発的に高額の請求が発生してしまう、なんてこともありえます。
例えば、テーブルを表示しようとするとすべての項目が表示されるため、更新の際はすべてが更新されることになります。そこに1,000件のレコードがあれば1,000件のレコードを同時に更新することになるということです。
一方で、Supabaseは有料プランは月25ドルからで徐々にアップグレードできる課金形態のため、限度額に達した場合は その都度少しずつ支払うことになり安心です。
また、Superbaseの場合、課金されるのは通信容量と保存されたデータの総量だけなので、もしSuperbaseのデータベースをあまり使っていないようなプロジェクトであれば無料でも様々な機能にアクセスできることになります。
💡 Tips
Superbaseでは、保存された画像サイズやビデオサイズを縮小し、使用しているストレージ容量を削減するためのクラウドファンクションやカスタムファンクションがあります。
そのため、Superbaseを使っている場合には使いすぎないようにするために いろいろと工夫することができます。
価格面では、使い方にもよるがSupabaseの方が安い場合が多そう。
比較②：ノーコードの範囲
どちらもアプリケーション開発に必要なことはほぼすべてノーコードでできます。データベースの作成からデータベースの読み込み、書き込み、削除まですべて特にコーディングの必要はありません。
チャット機能用の機能を作ることももできるし、プラグインやエクステンションを追加することもできます。
モバイルであればプッシュ通知を送ったりもできますし、ストレージを用意したりする部分も提供されておりますので、本当にいろいろなことがノーコードでできるようになっています。
ただし、少し細かいところを見ていくとノーコードでは対応できない範囲というのがあるにはあります。
APIの利用可否が争点か
Superbaseでは、管理画面上でAPIを作成でき、アプリケーションで直接APIを呼び出すだけでデータが使えるようになります。
つまり、Superbaseでテーブルを作成するたびにAPI URLが取得されるとうことで、具体的には特定のテーブルのデータを読み込んだり、データを作成したり、削除したり 更新したりするために使用できるURLを取得することができます。
Firebaseも同じようにテーブルを作成するたびに同様のことが実現できるようになりますが、FirebaseではAPIを直接取得することはできません。
コードの書き方を知っていなければ このリクエストを行うことができません。
しかし、FlutterFlowを使えばFlutterflowが裏ですべてやってくれるので自分で何かをする必要はなく、あくまでノーコードで使えるという範囲に留まると言えます。
ただし、一歩FlutterFlowから足を踏み出してこのFirebaseに溜まっているデータを活用して拡張サービスを作ろうとすると、APIがないことはデメリットになり、ノーコードでは対応不可になります。
まとめると、ノーコードの範囲という比較では、FlutterFlow以外のプラットフォームへの拡張性を鑑みるとSupabaseに軍配があがると考えます。
比較③：テクノロジー
NoSQL vs Relational Database
使用しているテクノロジーはFirebaseとSuperbaseの大きな違いであり、なんならこの違いのためにSupabaseは生まれたと言っているくらいのものです。
それは、FirebaseがNoSQLデータベースであるのに対し、Superbaseはリレーショナルデータベース（以下RDB）であることです。
RDBではテーブルにデータを保存する際にはMySQLフレームワークを使用します。MySQLは構造化クエリ言語であり、RDBではいつでもテーブルにMySQLクエリを書くことができます。
（この記事ではSQLに関しての説明は省略します。）
一方で、Firebaseはドキュメント型のNoSQLであり、ドキュメントを参照としてデータを保存します。
NoSQL（ノーエスキューエル）は、従来の関係型データベースとは異なるデータ保存のアプローチを指します。NoSQLは「非SQL」を意味し、柔軟なデータ構造や大規模なデータ処理に適したデータベースのカテゴリです。通常、スキーマレス（データ構造を予め定義しない）、水平スケーリング（サーバーを追加することで処理能力を向上）が特徴で、Webやモバイルアプリのようなデータ量やアクセスの急増に対応するのに適しています。主なNoSQLのタイプには、ドキュメント型、キーバリュー型、カラムファミリ型、グラフ型などがあります。
Firebaseを使う際に、たとえば同時に2つのものを保存したい場合はドキュメント参照を使います。実際に触ってみないと文章で表現するのはかなり難しいですが、関係性を表現する際にはもとのドキュメントに紐付けるサブドキュメントを定義するということです。RBSの設計のように構造化されてはいないものなのですが、2つのデータの間で参照関係を結ぶことさえできればそれらのデータを基本レベルで評価することができるという思想が背景にあります。これにより水平スケーリングが可能になりモバイル向けに特にデータの検索などが高速になるということを目指したものでした。
ではSupabaseを使うとFirebaseよりも遅いのか？
Supabaseの調査結果によれば、この採用テクノロジーの違いによるパフォーマンスへの影響は特になく、むしろSupabaseの方がパフォーマンスが良いという結果だったそうです。（あくまでSupabaseの調査結果なので僕が検証したわけではないです）
Supabase outperforms Firebase by up to 4x on number of reads per second, and 3.1x on writes per second.
この調査によれば、READではSupabaseの方がFirebaseより4倍速く、WRITEでは3.1倍速いという結果になったということです。
ここでもSupabaseに軍配があがりそうです。
比較④：利便性
管理画面の使いやすさ
管理画面のUIはどちらも同じくらい使いやすいです。
特にそれ以上のコメントはありません。笑
クエリの自由度
個人的にこれまでSQLに慣れた人間としてFirebaseを使っていて不便だなと思うのは複雑なクエリを作る時です。
FlutterFlow上ではそもそも複雑なクエリがノーコードの範囲では実現できないところがまだあります。
その際にSQLでは割りと複雑なクエリも簡単に書けたりするのですが、Firebaseの方は難しかったりします。（僕のFirebase知識不足もあるとは思いますが…）
セキュリティルールの設定
FlutterFlowではFirebaseを使用する場合に、FlutterFlowの管理画面上でセキュリティルールを設定することができ、セキュリティスタンダードに照らして公開しすぎている場合などはアラートあげてくれるのでかなり便利です。
一方で、Supabaseの方は（まだ）自分でSupabase上で設定する必要があります。
こちらもシンプルなものであれば特に問題ないのですが、セキュリティルールの設定に関して、Supabaseの場合はセキュリティルールはSQLで書かれている一方、Firebaseの方は独自のシンタックスで記載されており、複雑なルールを適用しようとするとSQLと比較してだんだんFirebaseの方が難易度はあがってくるという印象です。
結論、NoSQLのメリットないならSQL慣れている人ならSupabaseの方がよいですな。ということになります。
比較⑤：プラットフォームのリスク
テクノロジーに関するリスク
まず、Firebaseの使用するNoSQLは独自のものであり、SupabaseはPostgreSQLを使っており、こちらはオープンソースです。
その意味で、Firebaseを選択する場合はFirebaseにベンダーロックインされるリスクがありますが、Supabaseの方はそのリスクは低いと言えます。
運営者の事業継続性リスク
FirebaseはGoogleが買収しており、Googleが運営しているので基本的に事業継続性にリスクがあるとは考えにくいです。
その点、Supabaseに関してはまだまだスタートアップですが、調達額の大きさだけでも安心材料ですが、ユーザー数の急拡大を鑑みると「New Standard」として今後GAFA改めMATANA のどこかが買収して事業基盤が安定することも考えられますので、特に違いはないと言ってもよいのではないでしょうか。
まとめ
長々で5つの観点でFirebaseとSupabaseの比較をしましたが、個人的な推しはSupabaseです。
もちろん、FlutterFlowを使う前提ではFirebaseの方がもともとFlutterFlowの創業者たちがGoogle出身ということもあり、統合度合いが高く利便性が良いところはあるというのは事実です。
しかし、FlutterFlowにSupabaseが公式サポートされたことは、彼らがFirebaseもいいけどSupabaseの方がいい場面結構あるので選べるようにします！という時代背景かなと思います。
さいごに、SUNUP合同会社では事業開発をノーコードで高速に実現するご支援をしています。
FlutterFlowやその他ノーコードツールに興味がある、事業開発の伴走をして欲しいなどご相談は以下の当社ホームページよりお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？