「発明しない会社の設計思想——Supabaseはいかにして『編集』で50億ドル企業になったか」（DeepDive: Supabase）

シリーズ紹介

DeepDiveはテクノロジー企業に特化したビジネスケーススタディシリーズである。Supabase編では、PostgreSQLと既存OSSを束ねる「発明しない」設計思想が、なぜ評価額50億ドルの開発者基盤に育ったのかを扱う。

成功譚としてではなく、「どこまで自社で作り、どこから既存の強い部品を編集するべきか」を考える意思決定ケースとして読んでほしい。読むべき主役は、資金調達の金額ではない。言葉を変える判断、Launch Weekを制度にする判断、大口契約を断る判断、そしてAIがバックエンドを触る時代にガードレールを作る判断である。

Abstract

コードは同じだった。変えたのは、言葉だけだった。Supabaseは「real-time Postgres」を「open source Firebase alternative」と言い換えた瞬間、別の会社として読まれ始めた。

PostgreSQLは1996年から存在する。Realtime配信、認証、ストレージAPIも、世界中の誰かが作っていた。共同創業者Paul CopplestoneとAnt Wilsonが見つけた余白は、それらを再発明することではない。既存OSSで解ける部分は使い、足りない部分だけを自作してOSS化し、Postgres中心の開発者体験として編集することだった。

本稿は、Supabaseの6年間を「発明しない会社」の意思決定記録として読む。Firebaseの閉鎖性への違和感、Hacker Newsでの計画外爆発、Launch Weekという外部化された発表制度、元創業者30人以上を採用する組織論、そしてOrioleDB、Multigres、Hydraへの進出が示す限界までを、公式ブログ、GitHub、創業者インタビュー、投資家ノート、報道、コミュニティ反応から再構成する。

2026年4月時点で同社は800万人の開発者、GitHub 10万スター、評価額50億ドルに到達した。2025年9月時点では1日4万以上の新規データベースが作られ、Y Combinatorのポートフォリオ1,000社超が採用している。 だが問いは数字ではない。何を作るかより、何を作らないか。製品を変えるより、言葉を変えるか。準備してから出すより、出てしまってから学ぶか。読者が見るべきなのは、OSSを使えば勝てるという単純な話ではない。既存技術の束を、どんな順番、言葉、儀式、開発者体験で市場に差し出すかである。Supabaseは、技術企業の差別化が「発明」ではなく「編集」から生まれる条件を見せている。

一．二人が見つけた余白——Firebaseという失敗と「編集」という発想

ポール・コップルストーンが前職でFirebaseを捨てたのは、限界まで使い込んだからだ。

Googleが提供するFirebaseは、リアルタイム同期、認証、ストレージ、ホスティングまで含む完成度の高いBaaS（Backend as a Service）だった。「すぐに使える」代わりに、データはGoogleのサーバーに閉じ込められ、スケールすれば費用は跳ね上がり、移植は容易でない。ポールはこのトレードオフを体で知った。代替としてPostgreSQLを選ぶと、今度は「すぐには使えない」現実が待った。Realtimeのデータ配信はElixirで自前実装しなければならない。認証も、API生成も、すべてゼロから組む必要がある。

2019年時点で、この問いに対する市場の答えは二極化していた。一方に「完成しているが閉じている」商用BaaSがある。Firebase以外にも、MongoDB AtlasやAWS Amplifyが同じカテゴリーにいた。もう一方に「自由だが手間がかかる」セルフホスト型OSS構成がある。PostgreSQLを選んだ開発者が、Realtimeを自前実装するためにPhoenix FrameworkやElixirの学習コストを払い、Row-Level SecurityをSQL職人技で設定し、PostgRESTでAPIを生成し、GoTrueでJWT認証を設定し、S3互換ストレージを別途用意する——これが「自由を選んだ代償」だった。

ここで問いを一つ置いておきたい。あなたがポールと同じ立場にいたとして、この二択——便利だが閉鎖的なFirebase、自由だが手間のかかるPostgres——のどちらを選ぶか。あるいは、第三の道はあるか。

2019年末、ポールはシンガポールのEntrepreneur First（EF）というスタートアップ育成プログラムで、アント・ウィルソン（Ant Wilson）と出会った。EFは、技術者や研究者が単独で参加し、共同創業者を見つけ、アイデアを試す仕組みを持つプログラムだ。「七人でシェアハウスをシェアしていた」とアントは後年のインタビューで振り返る。「シンガポールのそんなに高くない家をシェアしていた」（ceoinsider.io, 2025年）。
アントには一度の起業経験があった。うまくいかなかった記憶は、何がプロダクトの本質で、何が枝葉かを峻別する感覚を研ぎ澄ませていた。

ふたりが見つけた答えは、第三の道だった。

「発明箇所を絞る」という選択だ。既存OSSで解ける部分は徹底して使い、足りない部分だけを自作してOSS化する——その境界線を意識的に引くことが、Supabaseの基本設計になった。GitHubのREADMEにはこう書かれている。

「Supabase is an open source Firebase alternative. We are building the features of Firebase using enterprise-grade open source tools.（SupabaseはオープンソースのFirebase代替だ。エンタープライズグレードのOSSを使って、Firebaseの機能を構築している）」。

さらに「if the tools don't exist we build them and open source them（ツールが存在しなければ自分たちで作り、OSSにする）」とも続く（github.com）。

具体的に、何を使い、何を作ったか。RESTful APIの自動生成にはPostgREST（Haskellで書かれた既存OSS）を採用した。当時のHaskellコミュニティの外ではほとんど知られていないツールだったが、PostgreSQLのスキーマを読んで自動的にREST APIを生成する設計の品質は、ゼロから実装するより明らかに優れていた。認証にはGoTrue（Auth0出身のエンジニアらが開発したOSS）を使い、後に独自改修してOSS化した。Realtimeだけは「既存に使えるものがない」と判断し、PostgreSQLのchange data capture（CDC）をWebSocket経由で配信するシステムをゼロから作った。ストレージはAmazon S3を背後に置き、その上にAPIと権限管理の層を独自実装した。

何を作らなかったか、も同じくらい重要だ。PostgreSQL本体のコードには最初の数年間ほとんど手を入れなかった。フロントエンドのホスティングは「提供しない」と決めた。独自のクエリ言語を設計する方向にも進まなかった。「Postgresそのものを使えばいい」というのが答えだった。SQLは世界中の開発者がすでに知っている言語だ。新しい抽象を作ることは学習コストを転嫁することだ——それをSupabaseは最初から断った。

2020年前半に、YCombinator（YC）のS20コホートに採択された。YCのデモデイという外部締切が、初期のプロダクト開発を加速した一因だ。しかし後に述べるように、Supabaseはデモデイよりも先に、計画外の爆発的露出を経験することになる。

Felicisのシリーズ B投資メモに、この思想が一文で要約されている。「don't reinvent the wheel, assemble a better car（車輪を再発明するな、もっと良い車を組み立てろ）」（felicis.com, 2022年）。

SupabaseはPostgres、PostgREST、GoTrue、Realtimeなど、すでに存在する優れたOSSを一つのUI、一つの料金体系、一つの運用体験へと統合した。

「編集」は知的労働だ。どのOSSを選び、どう組み合わせ、何を外に出し、何を中に隠すか——その判断の質が競合との差を決める。「組み合わせるだけなら誰でもできる」という批判が常に存在する。しかし、無名のPostgRESTに賭け、GoTrueを改修することを選び、Realtimeだけは自作すると決めた——その選択の連鎖は、優れたOSSキュレーターとしての審美眼なしには成り立たない。ここで重要なのは、作ったものだけでなく、作らなかったものの一覧である。ただし、この設計思想が最初に試された場所は、製品コードではなかった。言葉だった。

二．言葉が変わり、世界が変わった——ピボットとHNの連鎖

2020年春、Supabaseは言葉だけを変えた。

「real-time Postgres」を「open source Firebase alternative」に。製品に触れていない。機能は何も追加していない。変えたのは、説明だけだ。その結果について、アント・ウィルソンはこう語っている。

「"Same product, better words."（製品は同じでも、言葉は良くできる）」。

そしてその効果は「day and night（昼と夜ほどの差）」だったと（ceoinsider.io, 2025年）。

なぜこれほど効いたか。三つの理由がある。

第一に、比較対象を先に置いた。「open source Firebase alternative」という言葉を聞けば、Firebaseを知る開発者は即座に「ああ、Firebaseみたいなものか。でもオープンソースなのか」と理解できる。新しい概念を説明するコストがゼロになる。第二に、感情的なポジショニングだ。「閉じ込められたくない」「移植できないのが怖い」という開発者の感情に、「open source」という二文字が直接刺さる。第三に、「alternative」という言葉が示す乗り換え先の存在だ。不満はすでにある。後は選択肢を示すだけでいい。

コードを一行も変えずに、市場への届き方を根本から変えた。多くのスタートアップが「次はどんな機能を作ればユーザーが増えるか」を問うとき、Supabaseは「今の機能をどう表現すればユーザーに届くか」を問うた。開発者は毎日数十のツールを比較評価している。その限られた注意を獲得するためには、「なんだかよさそう」ではなく「ああ、あれの代替ね」という一瞬の解釈フレームが必要だ。「real-time Postgres」は技術的に正確だった。しかし技術的な正確さは、市場での速度に直結しない。

この言葉のピボットがどれほど機能したかを証明する出来事が、翌月に起きる。

2020年5月27日、Supabaseの初期ユーザーの誰かが、Hacker Newsに投稿した。ポールとアントが計画していた「Demo Day直前の計画的公開」ではない。まだ製品は粗かった。AuthもStorageも未実装。本番環境対応には程遠い初期版が、突然世界中のエンジニアの目に晒された。

HNのコメント欄は熱狂と批判が混在した。「That's pretty much what I've been wanting for years.（まさに何年も欲しかったものだ）」という声の横に、「DB is the last thing.（DBは最後の問題だ）」「just the API isn't really going to cut it.（APIだけでは足りない）」という指摘が並んだ（news.ycombinator.com, 2020年）。

ホストDB数は一夜で10倍になる。準備が整っていない段階での急激な負荷は、製品の弱点を容赦なく暴いた。

ポールとアントは、その場で二つの行動を取った。

一つ目は、コメント欄に直接返信すること。「APIだけでは足りない」という批判に対して、ポールはその批判が正しいことを認め、AuthとStorageが次のロードマップにあることを公開の場で約束した。「now building Realtime which is basically the secret sauce of Firebase」という返信は、路線を守りながら次の一手を示すメッセージだった（news.ycombinator.com, 2020年）。
批判を無視するのでもなく、過度に謝るのでもなく、設計思想の根拠と次の方向を同時に示す——これはプロダクト開発者としての自信がないとできない応答だ。

二つ目は、混乱を文書化して公開すること。二ヶ月後の2020年7月10日、「Alpha Launch Postmortem」を公開した（supabase.com/blog/alpha-launch-postmortem）。

何がうまくいき、何が壊れたか。HNへの露出前後のホスト数の変化、どのAPIエンドポイントが最初にボトルネックになったか、どんなエラーが頻発したか——定量データとともに、開発者が読んで次に学べる形で整理された。これは反省文であると同時に、「失敗を隠さず公開する」という文化の制度化だった。

この Postmortem 文化はその後も続く。2026年2月12日に大規模障害が発生した。翌日、詳細なポストモーテムが公開された（supabase.com/blog/supabase-incident-on-february-12-2026）。

障害の根本原因、影響範囲、タイムライン、再発防止策——すべてが公開のドキュメントになった。「Culture does not spread by itself. Write it down.（文化はひとりでには広がらない。書き残せ）」とアントは言う（ceoinsider.io, 2025年）。

SupabaseのGitHubリポジトリには、設計文書、インシデントの振り返り、ADR（Architecture Decision Record）が蓄積されている。これらは採用候補者も、既存ユーザーも、競合も読むことができる。透明性はコスト（競合に情報を与える）でもあるが、信頼の蓄積という長期的便益の方が大きいというのがSupabaseの立場だ。

HNの計画外爆発は災難ではなく、学習の密度を何倍にも高める最初の試練だった。「準備が整ってから出す会社」になることを諦めた瞬間、Supabaseは「出てしまってから耐え、学び、反復する会社」へと変貌した。その転換が、次の問いを生む——出すことを繰り返せる仕組みをどう作るか。

三．作らない、出す、繰り返す——制度になった哲学

「なぜローンチを1回だけにするのか？」