AIのSupabase推薦は、なぜ偶然ではないのか
バイブコーディングをしていると、AIはしきりにSupabaseを勧めてきます。最初は一時の流行か、学習データの偏りのように見えますが、データベースとストレージがもともとまったく別の系譜の技術だったことを思い出すと、話が変わります。なぜこの二つが今日、一つの道具の中に束ねられて出てくるのかを知ると、その推薦は好みというより、技術史の必然に近いことが見えてきます。
そこで本稿は、Supabaseの機能を並べる代わりに、データベースとストレージがそれぞれどんな問題にぶつかり、どう進化し、その二つの流れがどこで出会ったのかをたどります。この地図が頭にあれば、どの道具をなぜ使うのか、AIに何をどう指示すべきかが、あわせて明確になります。
データベースは、どんな問題を解きながら進化したのか
データ管理は、表計算のようなファイルから始まりました。便利でしたが、規模が大きくなると、重複、不整合、検索の非効率、そして複数人が同じファイルを同時に直すときの衝突が積み重なりました。1970年、エドガー・コッド(Edgar Codd)はデータを表(テーブル)に分けて保存しようという論文を発表し、この「関係モデル」という発想はその後五十年近くデータ管理を支配しました。
しかしサービスがサーバー一台では捌けないほど大きくなると、限界が露わになりました。表の厳密な正確さの一部を手放す代わりに、複数のサーバーに分けて持つ拡張性を得たNoSQLが登場し、データベースを自分で設置・運用すること自体が負担になると、その運用を代わりに引き受けるクラウドデータベースが現れました。ファイル→表→分散→クラウドと続くこの流れは、すべて「より大きな規模を、より少ない運用負担で」という一つの方向を向いています。
ストレージは、なぜサーバーから切り離されたのか
画像や動画といったファイルを保存するストレージも、似た道を歩みました。最初は、アプリケーションが動くサーバーにファイルをそのまま積んでいました。問題は、そのサーバーが落ちるとファイルも一緒に消えてしまうことでした。この脆さを味わってはじめて、2006年にAmazon S3がファイル保存をアプリケーションサーバーから丸ごと切り離し、専用の独立した場所へ移しました。
ファイルがサーバーから独立すると、今度は「世界中のユーザーへどう速く届けるか」が課題になり、ユーザーの近くにファイルの複製をあらかじめ置いておくCDNが、その配信速度までも解決しました。データベースが正確性と拡張性のあいだで進化したとすれば、ストレージは信頼性と配信速度を順に解きながら、サーバーから独立していったわけです。
合流点であるSupabaseは、指示をどう変えるのか
Supabaseは、この二つの流れが出会う合流点です。Firebaseの手軽さの上に、きちんとしたPostgreSQLデータベースを載せ、ユーザー認証とファイルストレージまでを一つのプラットフォームに束ねました。かつてはデータベースは別、ストレージは別、認証は別に用意し、一つひとつ手で繋がなければならなかったものが、いまや最初から繋がった状態で出てくる時代になったのです。AIがバイブコーディングでSupabaseを繰り返し勧める理由は、ここにあります。散らばっていた部品を一度に立ち上げられる道具だからです。
この地図が頭にあれば、AIへの指示の水準が変わります。たとえば「画像をデータベースにそのまま入れると遅くなるから、ファイルはストレージに上げ、データベースにはそのアドレス(URL)だけを保存して」と具体的に言えるようになります。道具のボタンの位置を知っていることと、その道具がなぜそんな形をしているのかを知っていることは、最終的に指示の正確さで分かれます。非開発者向けのバイブコーディング教育で、道具の使い方よりこの系譜から押さえる理由が、まさにそれです。系譜を理解した人は、AIを手ではなく判断で動かします。