個人開発SaaSのデータ基盤選定｜なぜSEGOはBigQueryではなくSupabaseを選んだのか

外資系SEOスペシャリスト

Takuma Oka (岡 拓馬)

こんにちは、岡 拓馬（おか たくま）です。
このブログでは、海外ノマド×SEO×ストック収入をテーマに、自分の経験や学びを発信しています。

高校卒業後は料理人としてスタートし、その後、航空自衛隊での勤務を経て、2016年からWebライター・SEOコンサルタントとして独立。現在は、海外の外資系企業と契約しながら、フルリモートで働いています。拠点はアジア各国を転々としており、最近はベトナムやタイ、マレーシア、フィリピンなどでノマド生活をしています。

執筆者

こんにちは、岡 拓馬（@OkaTakuma1）です。

Web の SEO 診断と AI 検索（GEO / LLMO）対応をまとめて診断できる無料ツール「SEGO」を、個人で開発しています。2026年4月30日に launch して以降、ありがたいことに診断件数が少しずつ積み上がり、現時点で累計2,024件のサイトを診断してきました。

先日、SEGO の診断データをブログ記事化していたときに、AI ペアプロのパートナーからこんな質問をもらいました。

結論から言うと、SEGO で使っているのは BigQuery ではなく Supabase（PostgreSQL）です。

ただ、この質問を機に「なぜ BigQuery ではなく Supabase なのか」を改めて言語化してみると、個人開発 SaaS のデータ基盤選定における原理原則が見えてきました。

本記事では、SEGO の選定プロセスを公開しながら、個人開発の SaaS・スタートアップでデータ基盤を選ぶときの判断軸を整理します。

＼ SEGOでサイト無料診断 ／

SEGO のデータ規模と用途

データ基盤の選定は、まず「何を扱うか」の言語化から始めます。SEGO の現状を正直に書き出すと、次のとおりです。

項目	現状
累計診断件数	2,024件（2026年5月時点）
主なテーブル	diagnoses / diagnosis_items の2つ
diagnosis_items の行数	約60,000行（2,024件 × 約30項目）
主な用途	診断結果の保存・取得・集計
アクセスパターン	1件ずつの読み書きが中心

個人開発の SaaS として、これは「とても標準的な規模」です。むしろこの規模感を正しく認識しておくことが、後の選定で過剰な技術を選ばずに済むコツでもあります。

アクセスパターンも重要です。SEGO は、ユーザーが URL を入力すると診断結果を即座に表示し、後から再閲覧されたり集計画面で平均値を出したりします。

1件ずつのリアルタイムな読み書きが主役で、巨大なデータをまとめて集計するワークロードは、現状ほぼ発生していません。

評価軸を3つに絞る

選定の議論は、軸を絞らないと「あれもこれも」で前に進みません。

SEGO では、次の3軸に絞りました。

この3軸は、機能の細かい優劣ではなく、「個人開発者が一人で運用し続けられるか」という視点で並べています。

Supabase（PostgreSQL）の評価

結論として SEGO が選んだのは Supabase です。

Supabase は、世界標準のリレーショナルデータベース PostgreSQL をホスティング型で提供する BaaS（Backend as a Service ＝ バックエンド機能を丸ごと提供するサービス）です。

用語を少しほぐすと、こうなります。

SEGO が Supabase を選んだ理由は、3軸で評価したときに次のように噛み合ったからです。

評価軸	Supabase の評価
規模	数百万〜数千万行までは余裕。SEGO の60,000行は十分以下
コスト構造	無料枠＋月額固定で予測可能。料金表は Supabase Pricing 参照
開発者体験	認証・行レベルアクセス制御（RLS）・REST API 自動生成が標準装備

特に効いたのは 開発者体験 です。

個人開発で時間が一番足りないのはコーディングそのものではなく

• 「認証まわりの実装」
• 「権限制御」
• 「API の用意」

といった周辺の地味な仕事です。

BigQuery を選ばなかった理由

では、BigQuery はどうだったのか。BigQuery は Google Cloud のデータウェアハウス（分析専用に最適化された、大規模データを扱うための DB）です。

よく Supabase と並べて議論されますが、両者はそもそも用途が違うツールです。

違いを表に整理します。

観点	Supabase（PostgreSQL）	BigQuery
主な役割	アプリの読み書き処理（OLTP）	大量データの集計・分析（OLAP）
得意なこと	1件ずつのリアルタイムなCRUD	数億行の集計クエリ
コスト	月額固定（無料枠あり）	クエリ実行ごとの従量課金
適正データ量	〜数千万行	数千万〜数兆行
SQL方言	標準 PostgreSQL	BigQuery 独自方言
典型的な使われ方	Web アプリのバックエンド	分析・BI・データレイク

用語注釈を補足します。

理由1：用途と一致しない

SEGO のアクセスパターンは、1件ずつの読み書きが主役です。

BigQuery は数億行の集計には最適ですが、1件取り出すだけのクエリでも数秒かかることがあります。

「リアルタイムにユーザーへ結果を返す」用途には向かないのです。

理由2：従量課金がスケール時に怖い

BigQuery の料金は、公式の料金ページ にあるとおり、クエリが読み込んだデータ量に応じた従量課金です。

これは大規模分析では合理的ですが、Web アプリのバックエンドに使うと、アクセスが伸びるほどコストが読めなくなるという不安が常にあります。

個人開発の SaaS でランニングコストが予測できないのは、精神衛生上もよくありません。

理由3：現状の規模に対して過剰

BigQuery が威力を発揮するのは、データ量が数千万〜数億行を超えた領域です。

SEGO の現状は60,000行で、これは PostgreSQL なら「鼻歌で処理できる」規模感です。

launch 直後のサービスに対して、データウェアハウス級の道具を持ち出すのは、家庭用の調理に業務用オーブンを買うようなものです。

個人開発で気をつけたいのは 「早すぎる最適化（Premature Optimization）」 です。

まだ存在しない問題に備えて、現在のシンプルさを犠牲にする ── これは個人開発の停滞を生む最大の罠だと、自分は思っています。

BigQuery に移行すべきタイミング

では、Supabase だけで未来永劫やっていくのか。これも違います。

データが伸びれば、いずれ BigQuery のようなデータウェアハウスを「分析用」に併用する日が来ます。

大事なのは「いつ移行するか」の判断基準を先に決めておくことです。

後から焦って決めるのではなく、平穏な今のうちに線を引いておく。SEGO では次のように決めています。

シグナル	対応
テーブルが数千万行を超え始めた	BigQuery 移行の検討開始
集計クエリが全クエリの3割を超えた	分析専用に BigQuery 併用
PostgreSQL の集計クエリが秒単位で遅くなった	マテリアライズドビュー → BigQuery
ユーザー向け管理画面で重い集計を表示したい	事前集計 or BigQuery 併用

大事なのは 「Supabase か BigQuery か」の二者択一ではない ことです。

実務では、メインの DB として Supabase を使いつつ、分析だけ BigQuery に同期するハイブリッド構成が一般的です。

AWS なら RDS、GCP なら Cloud SQL といった選択肢も含めて、用途ごとに最適な道具を組み合わせるのが現代的な設計です。

個人開発者が学んだ3つの教訓

SEGO のデータ基盤選定を振り返って、個人開発の文脈で再現性のある教訓を3つ書き出しておきます。

教訓1：「流行っているから」ではなく「用途に合うか」で選ぶ

BigQuery も Snowflake も Databricks も、それぞれ素晴らしい道具です。

ただ、「みんな使っているから」「名前を聞いたことがあるから」で選ぶと、ほぼ確実にミスマッチを起こします。

技術選定の出発点は、自分のサービスのデータ規模とアクセスパターンです。

流行は、その後で照らし合わせる二次情報にすぎません。

教訓2：早すぎる最適化を避ける

個人開発で一番もったいないのは、launch する前に過剰な技術選定で時間を溶かすことです。

SEGO も、最初から「いずれ億単位になるかも」と考えて BigQuery を組んでいたら、launch は半年遅れ、初期ユーザーの声を聞く機会も失っていたはずです。

シンプルなまま動かして、市場の反応に応じて拡張する。これが個人開発の王道だと思います。

教訓3：移行基準を事前に決めておく

「いつ移行するか」を決めずに走り出すと、データが膨れ上がってから慌てて対応することになります。

launch 前の平穏な時期に 「何行を超えたら検討開始」「何秒を超えたら警戒」 という具体的な線を引いておくと、判断が必要な瞬間に冷静でいられます。

これはデータ基盤に限らず、サーバー構成・課金プラン・運用ツールの選定にも応用できる考え方です。

個人開発の技術選定は「シンプルさ」を優先する

SEGO のデータ基盤を Supabase に決めた理由は、ここまで書いてきたとおり「現状の用途に対して、最もシンプルかつ運用可能な選択肢だったから」です。

「BigQuery のほうが格好いいから」とか「流行っているから」という理由ではありません。

個人開発 SaaS の launch を考えている方、すでに動かしているけど技術選定に迷っている方の参考になれば嬉しいです。Supabase の運用面に踏み込んだ話は、姉妹記事「個人開発の SaaS を launch する前に、絶対やるべきセキュリティチェック5つ！Supabase の脆弱性を実例で解説」で詳しく書いていますので、あわせてどうぞ。

SEGO そのものを試してみたい方は、無料診断ツールとして公開しています。URL を入力するだけで、SEO・AI 検索対応の現状を診断できます。

＼ SEGOでサイト無料診断 ／

※ 本記事は岡 拓馬が執筆・編集しています。執筆プロセスでは AI（Claude）を壁打ち相手として活用し、技術選定の言語化を進めました。最終的な判断・記述内容については、すべて筆者の責任において公開しています。