最近、「とりあえずPostgreSQLでいいじゃん」という声をよく聞くようになりました。

Stack Overflowの開発者調査でも、ここ数年、
「最も使われているDB」の1位はPostgreSQLです。
JSONを柔軟に扱えるJSONB型に加え、
拡張機能のpgvectorを入れれば、
生成AIで使うベクトル検索までこなせてしまうので、
人気が出るのも納得です。

一時期は「これからはNoSQLの時代！」なんて言われていたのに、
気づけばRDBが一周回って主役に返り咲いている感じですね。

……で、そもそもNoSQLって何だったんでしょう？

普段RDBを触っていると、
NoSQLをちゃんと使う機会は意外と少ないものです。
「名前はよく聞くけど、実際どういうもの？」
「テーブル定義がないってどういうこと？」と、
フワッとしたイメージのままの人も多いと思います。

そこで今回は、どっちが優れているかという話ではなく、
普段RDBを使っている人が「NoSQLってこういう文化なのね」とざっくり掴むための話をしてみます。

そもそも「NoSQL」にもいろいろある

NoSQLは、ひとつの技術の名前ではありません。
RDB以外のデータベースをまとめて呼ぶ言葉で、
中身はいくつかのタイプに分かれます。

今回は、この中でもRDBの人がいちばん出会いやすいドキュメント型を中心に話を進めます。

RDBは今も王道、NoSQLは「特化型の飛び道具」

NoSQLという言葉が広まったのは2009年頃で、
ビッグデータや大規模Webサービスへの爆発的なアクセスを捌くために注目されました。

とはいえ、冒頭でも触れたとおり、王道はいまだにRDBです。
データベースの人気を集計しているDB-Enginesでも、
データモデル別に見ると、
RDBが人気スコアの大部分を占めています。

NoSQLは、RDBを置き換えるものではありません。
サーバーの台数を横に増やして大量のアクセスを捌きたい（水平スケール）、
データ構造がコロコロ変わる、
といったRDBが苦手な領域を補うための飛び道具という立ち位置です。

実際の現場でも、「NoSQLだけ」でシステムを組むケースは少数派です。
メインはRDBに置いたうえで、
キャッシュやセッションにRedis、
大量のイベントデータにDynamoDB、
といった形で部分的に併用するのが一般的です。

お金や在庫を厳密に管理する業務システムでは、
引き続きRDBが主役です。
なので、「NoSQLを触ったことがない＝遅れてる」なんてことは全くありません。

RDBは「データ中心」、NoSQLは「アクセスパターン中心」

一番の違いは、データの持ち方に対する考え方です。

RDBは、最初にカッチリとスキーマ（テーブル定義）を決め、
正規化してデータの重複や不整合を徹底的に防ぐ、
「データ中心」の思想です。
画面に表示するときは、
分割されたテーブルを都度JOINして組み立てますよね。

一方、MongoDBやFirestoreといったドキュメント型のNoSQLは、
厳密なスキーマを持たず、
「画面でそのまま使いたい完成形」をJSONの塊としてまるごと保存します。
「どう読み出すか」から逆算して設計する、
「アクセスパターン中心」の思想です。

たとえば「注文」のデータで比べてみると、こんな違いになります。

NoSQLでは、JOINをしなくて済み、
データやアクセスが増えてもサーバーを増やして速さを保てます。
その代わり、顧客名のような同じデータがあちこちに重複しますし、
想定していなかった切り口での検索や集計は苦手です。

速さと規模の大きさと引き換えに、
そうしたトレードオフを受け入れる設計なんですね。

「スキーマがない世界」の秩序の守り方

RDBに慣れていると、
「DBに制約がないなんて、ゴミデータが入ってカオスになりそうで怖い…」と感じるはずです。

これはエンジニアとしてとても健全な感覚で、
実際に何のルールも決めずに運用すると、
データ構造はあっという間に崩壊します（いわゆる「スキーマレス地獄」）。

では、NoSQLの世界でどう安全を守っているかというと、
アプリケーション側で型を定義し、整合性を担保するのが定石です。
TypeScriptの型定義やバリデーションライブラリを使って、
書き込む前にガチガチにチェックするわけですね。

なお、DB側にも検証の仕組みがまったくないわけではありません。
MongoDBにはスキーマを検証する機能があり、
Firestoreもセキュリティルールで書き込める内容を制限できます。

つまり、「スキーマがない」のではなく、スキーマを持つ場所が、
主にDBからアプリに移っていると捉えると、
イメージしやすいと思います。

「書いたのに古いデータが返ってくる」？ 一貫性の違い

RDBの人がもうひとつ戸惑いやすいのが、一貫性の考え方です。

RDBでは、トランザクションで書き込みが確定すれば、
その直後に読み出したときには必ず新しいデータが返ってきます。
これは当たり前のことに思えますよね。

ところが、たくさんのサーバーにデータを分けて持つ分散型のNoSQLでは、
書き込みがすべてのサーバーに行き渡るまでに、
ほんの少し時間がかかることがあります。
そのため、書き込んだ直後に読み出すと、
古いデータが返ってくる場合があるのです。

「少し待てば、いずれ全部のサーバーで同じデータになる」というこの考え方を、
結果整合性と呼びます。

多くのサーバーで大量のアクセスを捌くために、
「常に最新」をあえてゆるめている、というわけです。
ただし、DynamoDBのように、
必要な場面では最新のデータを読む（強い一貫性の）オプションを選べるものもあります。

お金や在庫のように「1円のずれも許されない」データでRDBが選ばれ続けているのは、
この一貫性の違いも大きな理由です。

だから今、PostgreSQLが選ばれている

ここまで読むと、冒頭の「とりあえずPostgreSQL」の理由が見えてくると思います。

NoSQLの強みだった「柔軟なデータ構造」は、
JSONB型である程度カバーできるようになりました。
そのため、わざわざNoSQLを別で立てて運用コストを増やすより、
まずはPostgreSQLで堅牢に設計し、
柔軟さが欲しい部分だけJSONBを使う、
という設計がかなり一般的になっています。

もちろん、桁違いのアクセスを水平スケールで捌きたい場面では、
今でもNoSQLの出番です。
最近は、Google Cloud SpannerやCockroachDB、
TiDBのように、SQLを使いながら水平スケールできる「分散SQL」という選択肢も増えてきました。

「まずRDB、足りない部分をNoSQLや分散SQLで補う」という考え方が、
2026年時点のバランスのいい落としどころと言えそうです。

おわりに

RDBとNoSQLは、「どっちが上」ではありません。
そもそも、解決したい課題と設計の出発点が違います。

RDBはデータの正しさから考え、
NoSQLは読み出し方から考える。そして最近は、
PostgreSQLのような多機能なRDBで、
両方のいいとこ取りをする選択肢も増えています。

「そういう世界観もあるんだな〜」くらいに知っておくと、
クラウドのアーキテクチャ図やモダンなWeb系の記事を読むのが、
ちょっと面白くなるかもしれません！