データ管理はなぜファイルから表へ移ったのか
データ管理はExcelのようなファイルから始まりました。顧客ファイル、注文ファイル、社員ファイルと別々に作っていくと、四つの問題が積み上がります。同じ人の情報が複数のファイルに重複し、ファイルごとに在庫の数字が食い違ってどちらが正しいのか分からず、検索にはファイル全体を走査するしかなく、二人が同時に保存すると片方の修正が消えてしまいます。
1970年、IBMの数学者エドガー・コッドが解決策を示しました。データを行と列のある表として保存し、表同士をジョインでつなぎ、同じ情報は一箇所だけに置く正規化で重複をなくすという考え方です。このリレーショナルモデルとSQLがその後50年を支配し、1977年のOracle、1995年のMySQL、そしてPostgreSQLがこの土台の上に生まれました。
NoSQLとクラウドDBは何と引き換えに何を得たのか
2000年代半ばにソーシャルメディアが登場すると、サーバー1台をより良い機材に替える垂直スケーリングが限界にぶつかりました。表を複数のサーバーに分割するとジョインが遅くなるため、正確性の一部を手放す代わりに速度と水平スケーラビリティを得たNoSQLが生まれました。だからこそ、正確性が命の銀行は今もリレーショナルDBを使い、ソーシャルメディアはNoSQLを使います。
2010年代には、インストール・バックアップ・容量管理をクラウドが肩代わりするマネージドDBが一般化しました。DBは自分でインストールするものから、電気のように差し込んで使うものへ変わったのです。
ストレージはなぜサーバーから切り離されたのか
ファイル保存も同じ道をたどりました。初期のWebサービスはサーバーのアップロードフォルダにユーザーのファイルを積み上げていましたが、サーバーが落ちればファイルも一緒に消え、サーバーを増やせばどのファイルがどこにあるのか混乱し、ファイル転送だけでトラフィックが詰まりました。2006年、AmazonのS3がファイル保存をサーバーから切り離しました。ファイルをアップロードすると複数のサーバーに複製して保管し、アクセス用のURLを一つ返すオブジェクトストレージ方式です。さらにCDNが世界中のエッジサーバーにファイルをあらかじめ複製しておくことで、配信速度の問題まで解決されました。
Supabaseは何を一つに束ねたのか
2020年に登場したSupabaseは、この二つの流れの合流点です。Firebaseは認証・DB・ストレージを一度に提供して人気を得ましたが、NoSQLベースのため複雑なリレーショナルデータや精緻なクエリには弱いものでした。Supabaseは同じ手軽さを本格的なPostgreSQLの上に載せました。テーブルを作ればAPIが自動生成され、ファイルのアクセス権限もDBのユーザー情報と連動して管理されます。サービスを一つずつ別々に組み付ける時代から、必要なものが最初からつながった状態で手に入る時代へ変わったのです。
非開発者がこの系譜を知ると何が変わるのか
指示のレベルが変わります。画像をDBに入れると遅くなるからストレージにアップロードしてURLだけ保存するように、と言えるようになり、正確性が優先のデータと速度が優先のデータを区別して要求できるようになります。SH Consultingが非開発者向けのバイブコーディング教育で、ツールの使い方よりもまずこの系譜から押さえる理由がここにあります。