リリース前に Firebase 費用を下げる

リリース前に、フィード、検索結果、ダッシュボード、通知、プロフィールなど繰り返し使われる画面を並べます。それぞれの画面で読むドキュメント数、ダウンロードするファイル、実行される callable function、realtime listener による再読み込みを数えます。

この確認は、プロバイダーを変えるより早く大きな改善点を見つけられます。投稿、投稿者、カウンター、コメントを別々に読むフィードは、本番トラフィックが来る前に安い構造へ直せます。

一覧画面では authorName、thumbnailUrl、commentCount、likeCount、lastActivityAt、status など、表示に必要なフィールドを一覧で読むドキュメントに保存します。必要なら正規データは別に持ちつつ、1 行を表示するために関連ドキュメントを何度も取得する設計は避けます。

ページサイズも明確に制限しましょう。無限スクロール、検索補完、管理テーブルでは、活発なユーザー 1 人が通常操作だけで数千 read を発生させない設計が必要です。

Storage ダウンロード、Cloud Functions、長い保存期間は次の費用要因になり得ます。画像はアップロード前にリサイズし、公開アセットはキャッシュし、一時ファイルは削除し、ログや export はプロダクトに必要な期間だけ残します。

そのうえで、保守的なトラフィックと楽観的なトラフィックの両方を計算機に入れてください。それでも Firestore read やリレーショナルなレポートが費用の中心なら、構成を固定する前に Cloud Run + Cloud SQL と比較する価値があります。