SQLは死んだ。SQL万歳！
私は30年間、エンタープライズITの現場に身を置いてきました。数多くの流行が現れては消え、営業担当者やコンサルタントが「ビジネスに本当のゲームチェンジをもたらす」と約束した技術革新のうち、失敗に終わったものが山のように積み上がるのを見てきた年月です。
ここでは、まるで聖杯のように売り込まれながら、実際には一瞬の流行で終わったり、短い脚光のあとにニッチへ追いやられたりした例をいくつか挙げます。
しかし、その逆のケースもあります。何十年も前に死んだと宣告された技術が、AI の時代まで生き延び、今も元気に動き続けているのです。
技術採用に関する長期予測の多くは、単純に当たりません。
要因はいくつもありますが、ひとつだけ際立つものがあります。私たちは技術採用における慣性を、特にエンタープライズITでは慢性的に過小評価しているということです。
これは人間の性質にも多少関係しているかもしれませんが、主にはエンタープライズITの現場で働くプロフェッショナルの経験に根ざしています。もちろんITは、競争力を高め成長を後押しするために、ビジネスへ大きな効果をもたらすイノベーションを提供しなければなりません。しかし、ITリーダーシップの中核的な役割は、適切なバランスでリスクを管理し、コストを最適化し、事業を止めないことにあります。そこには人も技術も含まれ、単なる可用性やサイバーセキュリティをはるかに超える論点があります。
エンタープライズITではどのように意思決定が行われるのか
簡単な例を挙げましょう。CTOとして新しいプロジェクトのためにプログラミング言語を選ぶとき、私はその言語自体の機能だけを見ているわけではありません。意思決定においては、それ以外の要素のほうがむしろ重要です。社内の状況と市場全体の両方を見て、その言語がどれほど普及しているのかを理解する必要があります。その言語の開発者を採用しやすいのか、という点です。
たとえば2025年に新規プロジェクトでJavaScriptとRubyのどちらかを選ばなければならないとしたら、私はまず StackOverflowの調査 を見て、JavaScriptを知っている開発者は66%以上いる一方、Rubyを知っているのは6.4%しかいないことを確認するでしょう（Rubyはサーバーサイドの候補になり得ます）。その場合、たとえRubyのほうが優れているとしても、私はおそらくJavaScriptを選びます。採用しやすいというだけではありません。より大きな開発者コミュニティがあれば、ツール、サポート、プロフェッショナルサービス企業の存在といったエコシステムの厚みも期待できます。 同様に、採用マーケティングツール を選ぶ際にも、企業は堅牢なユーザーベースと強いエコシステム支援を持つプラットフォームを優先しがちで、
それが長期的な安定性と統合のしやすさにつながります。
次に見るべきは長期的なトレンドです。その言語はどれくらい前から存在するのか。採用は今も伸びているのか、頭打ちなのか、あるいは減少に転じているのか。新しいトレンドやイノベーションを取り込む形で発展し続けるのか。5年後、10年後にもサポートは存在するのか。
そして、SQLとその歴史についての話が本当に始まるのは、まさにここなのです。
SQLとは何か
SQLは、データ構造を定義し、データを操作し、問い合わせ、制御することを目的とした、広く使われている標準化されたプログラミング言語です。主に宣言型でありながら手続き的要素も持っています。リレーショナル代数に基づいており、VSAMのような従来のクエリやデータ操作技法を大きく前進させました。1つの文は、句、式、述語、クエリ、再帰的な副文から構成されます。
ベンダー固有の拡張や方言は常に存在してきましたが、言語の中核は主要な実装で標準に準拠しています。互換性の差異は主にデータ型やより高度な構文に現れます。
SQLは完璧ではありません。美しい数学的基盤に常に忠実というわけではなく、階層型データやグラフ指向データには最適ではなく、オブジェクト指向パラダイムにも決してうまくはまりませんでした。一般に、オブジェクト指向言語や手続き型言語のいずれとも滑らかには統合されません（そこでObject-Relational Mapping、つまりORMが登場します）。より複雑な文は書くのも読むのも扱いにくくなり、大規模で複雑なロジックをSQLやPL/SQLだけで効率よく記述するのは得策ではありません。
だからこそ、時間の経過とともに多くの代替案が提案され、そのいくつかは大きな成功を収めました。たとえばグラフクエリ言語や、キー・バリュー型ストアやドキュメント指向データ向けのnoSQLです。
しかし、成功した代替技術の多くは最終的にニッチの中で頭打ちになり、実際ここ数年では、それらの一部がSQLへ回帰する動きすら見られます。一方で、JSONやグラフのような概念はすでに新しいSQLのバージョンに取り込まれており、代替技術の必要性を下げています。
SQLは古い。しかし、このマラソンでは明らかな勝者です。
SQLの起源
SQLの起源は1970年代初頭にさかのぼります。1970年、Edgar F. Coddは A Relational Model of Data for Large Shared Data Banks を発表し、リレーショナルデータベースのモデルを提示しました。
それはRDBMSの誕生でした。当時としてはまったく新しいITシステムのカテゴリであり、55年後の今でも、世界的に見てトップ3に入るカテゴリであり続けています（ITインフラやERPシステムと並んで）。RDBMSの普及はERPの台頭によって後押しされ、SQLの普及もそれと歩調を合わせて進みました。双子のようなもので、片方だけでは存在できません。
1974年から1977年にかけて、2つの主要なリレーショナルデータベースの試作システムが作られました。UC Berkeley（UCB）で開発されたIngresと、IBM San Joseで作られたSystem Rです。IngresはQUELというクエリ言語を使い、Ingres Corp.、MS SQL Server、Sybase、PostgreSQL、Wang’s PACE、Britton-Leeといったシステムの源流になりました。一方、System RはSEQUELというクエリ言語を使い、SQL/DS、DB2、Allbase、Oracle、Non-Stop SQLの発展に貢献しました。
また、この10年でRelational Database Management System、すなわちRDBMSという言葉が広く認知されるようになりました。
SQLの標準化と普及
SQLに関する約10年の研究開発を経て、1980年代はRDBMSの商用化と標準化の10年になりました。1980年代には複数の商用データベースシステムが登場しています。Oracle V2（1979）、Sybase SQL Server（1984）、IBM DB2 for Mainframes（1983、System Rの後継）、IBM Informix（1985）、Microsoft SQL Server 1.0（1987）、SAP DB（1988）などです。
重要な一歩となったのが、1986年と1987年にそれぞれANSIとISOがSQLを標準的なデータベース言語として採用したことです。この標準はその後も何度も改訂され、最新の改訂は2023年です。
ベンダーが標準化に乗った理由には、この成長市場で標準があれば市場全体の成長が速まるという期待、標準に対応しなければ競争で不利になるという懸念、標準そのものに影響を与えられること、そしてエコシステム上の利益がありました。
SQLの初期の成功は偶然ではありません。そこには明らかな需要がありました。
しかし、本格的な成長が始まったのは1990年代初頭からです。ハードウェア価格の低下、UNIXとPCによるクライアントサーバーアーキテクチャの普及、そしてERPの採用拡大がその要因でした。この10年は、MySQL（1995）、PostgreSQL（1996）、MariaDB（1999）といったオープンソースのリレーショナルデータベースが登場した時代でもあります。
リレーショナルデータベースの系譜は非常に複雑ですが、詳細はこちらで確認できます。
現在の状況と見通し
要するに、SQLはこれからも残ります。それどころか、かつてないほど活気があり、成長しています。この恐竜のような技術は、現代的な競合をすべて生き延び、人気でも上回ってきました。
これは、技術採用ライフサイクルやガートナーのハイプサイクルという概念が、長い目で見ると必ずしも当てはまらない好例です。SQLは定義上は完全に「後期段階」に入っているはずなのに、これまで以上のスピードで成長しています。たとえば2018年のGartner Hype Cycleでは、SQLはもはやカテゴリとしてさえ登場していませんでした（2025年でも同様です）。
この5年間で、SQLデータベースは単に生き残っただけでなく、むしろ栄えました。2020年のStack Overflow Developer Survey では、MySQLと PostgreSQL がすでに世界で最も使われるデータベースの上位に入っていました。2025年にはその優位性はさらに広がっています。MySQL、PostgreSQL、Microsoft SQL Server、SQLiteが、プロフェッショナル開発者に使われるデータベースのトップ4を占め、どのnoSQL代替よりも大きく先行しています。何年にもわたって「SQLは死んだ」と予言されてきましたが、データは逆を示しています。SQLは今なお、現代のソフトウェアとデータ駆動型システムの背骨なのです。
なぜSQLは再び生きているのか？
SQLがいま再び大きく返り咲いている理由について、私の4つの仮説を紹介します。ぜひ反論してください。皆さんの意見をとても聞いてみたいです。
基盤
SQLは、当時一般的だった手続き型言語に対して、最初期の宣言型言語のひとつでした。宣言型言語では、どうやって行うかではなく、何をしたいかを記述します。これは他のプログラミング言語にあまり慣れていないユーザーにとって非常に魅力的です。少なくとも基本的なユースケースでは学びやすく使いやすい一方で、柔軟性は非常に高く、アドホッククエリからトランザクション処理まで、幅広いデータアクセスパターンに適しています。
成熟
これほど長い時間をかけて開発され成熟してきた技術は、非常に安定していて完成度が高いとみなせます。意思決定者がSQLを選んだからといって、技術的な賭けをしているわけではありません。
普及
この点は冒頭でも触れました。SQLの採用レベルは長い年月をかけて上昇してきました。ゆっくりな時期もあれば速い時期もありましたが、いまやデータアクセス言語として圧倒的な支配的地位にあります。このポジションそのものが、今後の成長をさらに確かなものにしています。
競争優位に関するビジネス理論に少し寄り道すると、両面市場プラットフォームに基づく市場では、リーダーが圧倒的な競争優位を持つことが知られています。 SQLベースのリレーショナルデータベースは、広い意味でそのような両面プラットフォームを構成しています。
- コミュニティ（SQLの場合は特定のデータベースシステムごとに複数のコミュニティが存在します） – SQLユーザー、開発者、その他の専門家を含みます
- 産業側 – システムベンダー、プロフェッショナルサービス組織、クラウドサービスプロバイダー、その他の関係者を含みます。
ここで強いネットワーク効果が働きます。コミュニティが大きくなるほど、市場規模を収益化したい産業側によってエコシステムとシステム機能の成長が促進されます。同時に、技術を選ぶユーザーやその所属組織も、リスク管理や人材確保のためにコミュニティ規模を重視するため、コミュニティ自体もさらに拡大します。
この効果は非常に強力で、もともとそのために作られていなかったユースケースまでプラットフォームが「吸い込んで」しまうことがあります。たとえば、リレーショナルデータベース上でのグラフやベクターデータベース拡張がその例です。
進化
生物の進化と同じように、技術の進化における外部イベントは予測できません。起きた後に適応することしかできないのです。長期的な生存確率が最も高いのは、最も強い種でも、最も速い種でも、最も大きい種でもありません。変化に最もうまく適応できる種です。2025年のSQLは、もはや1970年のSQLではありません。
SQLはその過程で、ビッグデータや分散システム（シャーディングとパーティショニング、分散SQLデータベース、カラム指向ストレージとアナリティクス）、現代的なプログラミング言語やAI言語とのスムーズな統合、半構造化・非構造化データ（json、配列型、xml）のサポート、リアルタイムアナリティクスへの適応、高度な分析やMLのサポート（BigQuery MLやPostgreSQL拡張など）、AIパイプラインとの統合、インメモリ処理、ベクトル化クエリ実行、GPU加速MLなど、重要な変化を取り込んできました。
SQLの次は何か？
SQLは、自らの衰退を予測する声よりも速く進化できることを証明してきました。AI、ベクター検索、リアルタイムアナリティクスがアプリケーションの作り方を変える中でも、SQLは消えるのではなく適応し続けています。次の波はSQLを置き換えるものではありません。SQLを拡張するものです。SQLは AIに選ばれるデータベース です。AI主導のデータ処理とのより深い統合、ベクターネイティブな拡張、そしてデータベースをこれまで以上に動的にするクラウドネイティブなスケーリングが進んでいくでしょう。
何十年にもわたるハイプの移り変わりを見てきた私たちにとって、SQLの未来は懐かしくもあり新しくもあります。SQLは今もなおデータの言語ですが、今では知能の言語も話します。私の仮説やSQLの未来について、ぜひ皆さんのフィードバックを聞かせてください。
個人的には、SQLこそ今も未来だと考えています。だからこそ私たちは Vela を作っています。VelaはPostgresを基盤にしたモダンなBackend-as-a-Serviceプラットフォームです。こうして私たちは、Postgresが今日のクラウドおよびAIワークロードにおいてSQLをどう有効なものに保っているかを示せるのです。