比較 / Firebase
読み取り回数ではなく秒単位で課金する Firebase の代替
Firebase は read ごとに課金され、サーバーの代わりに functions を提供します。Lizard は PostgreSQL 18、Redis 8、S3-compatible object storage、そしてそれらの前段に置ける長寿命プロセスを提供します — すべて one command でプロビジョニングでき、計測された使用量に対して秒単位で課金されます。
開発者が Firebase の代替を探す理由
請求額は users ではなく reads に応じて増えます
Blaze の Firestore は 100,000 reads あたり $0.06、100,000 writes あたり $0.18、保存容量 1 GiB あたり $0.18 を課金します。1 回開くたびに 40 documents を読む一覧画面は、100 users なら誤差でも、100,000 なら請求項目になります。
Firestore はリレーショナルではありません
すべての join は denormalisation になり、すべての denormalisation は fan-out write になり、そこに課金されます。2026年4月に Data Connect から改名された Firebase SQL Connect は、現在 Postgres の道筋を提供しています — それ自体が論点を認めています。
サーバーがありません
Firebase では、requests の合間に生き続けるものはありません。Functions も App Hosting もどちらも request-driven なので、長寿命 consumer や open socket の置き場がありません。
1 つの SDK がすべてを支配します
Auth、database、storage、functions、hosting は単一の製品です。各要素は 1 つのプロジェクト、1 つのコンソール、1 つの請求を共有し、client SDK がそれらすべての使用へと誘導します。
Lizard vs Firebase
すべての数値は Firebase の公開料金表 と当社の料金表から読み取ったものです。最終確認: 27 August 2026.
| 比較した人 | Lizard | Firebase |
|---|---|---|
| データベース | PostgreSQL 18、リレーショナル、数秒で準備完了 | Firestore、document store |
| データベースの課金 | CPU、memory、disk を秒単位で計測課金 | 100,000 reads あたり $0.06、100,000 writes あたり $0.18、保存容量 1 GiB あたり $0.18 |
| サーバーコード | 長寿命プロセス、実行時間の上限なし | Cloud Functions、呼び出しごと、制限あり |
| WebSockets と streaming | 通常の長寿命 connections | streaming は可、2nd gen callable functions でのみ。WebSockets は不可 |
| キャッシュ | Managed Redis 8、one command | Firebase には該当製品がありません — VPC 経由で利用する Google Cloud Memorystore |
| オブジェクトストレージ | S3-compatible、あらゆる AWS SDK が動作 | Cloud Storage for Firebase |
| 認証 | 独自のものを使用可能 — Firebase Auth を気に入っているならそのまま利用できます | Firebase Auth、first-party で本当に優秀 |
| 無料枠 | $10 のトライアルクレジット、31 日間有効 | 1 日あたり 50,000 reads、20,000 writes、20,000 deletes、Blaze プランのまま |
Firebase のほうが適している場合
主に client が data store とやり取りする mobile app、特に初期段階ではそうです。Firebase Auth、Cloud Messaging、offline sync、client SDKs は優秀で再現が難しく、free tier だけでも実際の製品をかなり先まで支えられます。また、Firestore を離れることは Firebase Auth や Cloud Messaging を離れることも意味しません — それらはどんな backend とも問題なく組み合わせられます。
からの移行Firebase
Dockerfile は不要です — lizardpack がスタックを検出し、ビルドノード上で自動生成します。リポジトリに Dockerfile がすでにある場合は、そのまま使用されます。
よくある質問
Supabase は、Firestore の代わりに Postgres を使う点を含め、Firebase の製品全体に最も近い選択肢です。Appwrite と PocketBase はセルフホスト可能な選択肢です。アプリがクライアントサイドのデータレイヤーを超えて成長しているなら、マネージド Postgres の隣で自分の API を動かす形 — Lizard ではワン コマンドです — のほうが通常は適した構成です。
はい、しかもそれが最も安い最初の一歩であることがよくあります。Firebase Auth は、独自 backend が Google の公開鍵で検証できる JWTs を発行するため、sign-in はそのままに data layer だけを Postgres へ移せます。Cloud Messaging も同じように組み合わせられます。
gcloud firestore export でコレクションをエクスポートするか、Admin SDK で走査してから、ドキュメントの構造をそのままコピーするのではなく、まずリレーショナルスキーマを設計してください — その再設計が作業の大半です。移行中はデュアルライトを行い、フィーチャーフラグの裏側で読み取りを切り替え、その後完全移行します。
起動したままのものはありません。Cloud Functions は invocation ごとに実行され、cold starts と実行時間制限があり、Firebase App Hosting は Cloud Run に deploy されますが、それでも request-driven です。requests の間で state を保持しなければならない process — queue consumer、WebSocket server、scheduler — には、それを動かせる platform が必要です。
AI で構築。Lizard で公開。
本番公開にプラットフォームチームは必要ありません。クラウド全体が、1 つの CLI コマンドですぐ使えます。
- ワークスペース
- —
- サービス
- —
- アドオン
- —
- デプロイ
- —