データストア選定 ― RDB中心+用途特化の使い分け ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第2弾として、データストア選定について解説する記事です。

2026年は1アプリで複数ストアを用途別に使い分けるのが普通になりました。本記事はアプリ単位の詳細選定に特化し、RDB／KVS／ドキュメント／列指向／時系列／検索／ベクトルの各強み弱み、データ量×用途別の段階表を提示します（システム全体の配置方針は別記事「システムアーキテクチャ」へ）。

このカテゴリの他の記事

この記事の守備範囲

データストア選定はシステム全体の配置方針と個別アプリの詳細選定の2段階に分かれます。本記事は後者、つまり「アプリ単位で具体的なデータストアを選ぶ実務」に特化します。

記事	扱う範囲
10/06 データストア	システム全体の配置方針 / Polyglot Persistence / スケール戦略の全体地図
本記事	個別アプリの詳細選定 / 早期判定フロー / データ量×用途別の段階選び
40/02 データモデリング	テーブル設計・正規化・主キー・インデックス
40/03 データ基盤	DWH / データレイク / BI連携

本記事の問いは「このアプリにはどのDB種が適するか」全体配置はシステム章で扱います。

データストアは「引っ越し不可の家」

選択を誤ると速度が出ない・スケールしない・開発効率が落ちるといった根本的な問題に直結します。一方で種類が多すぎるため、まず業務要件の型を把握し、そこから適切なカテゴリを選ぶというアプローチが現実的です。

データストアは全てのアプリケーション設計の土台です。DBが決まらないとエンティティ設計・API設計・トランザクション境界の全てが決まりません。しかも一度運用が始まるとデータ移行は極めて高コストで、後から変えるは現実的に不可能に近い判断です。さらに、データストアはクラウドベンダーとの結びつきも強く、AWS Aurora から GCP Cloud SQL への移行のような「比較的近い製品間ですらハードルが高い」のが実情です。

「とりあえずRDB」は多くの場合正解。ただし例外を知っておくことが設計者の役目です。

主要な分類

flowchart TB
    DATA{扱うデータの<br/>性質は?}
    DATA -->|構造化・整合性必須| RDB[RDB<br/>PostgreSQL/MySQL]
    DATA -->|単純Key→Value<br/>超高速| KVS[KVS<br/>Redis/DynamoDB]
    DATA -->|柔軟スキーマ・JSON| DOC[Document<br/>MongoDB/Firestore]
    DATA -->|集計・分析| OLAP[列指向OLAP<br/>BigQuery/Snowflake]
    DATA -->|時系列・センサー| TS[時系列DB<br/>InfluxDB/Timescale]
    DATA -->|全文検索| SE[検索エンジン<br/>Elasticsearch]
    DATA -->|類似検索・AI| VEC[ベクトルDB<br/>pgvector/Pinecone]
    classDef root fill:#fef3c7,stroke:#d97706;
    classDef rdb fill:#dbeafe,stroke:#2563eb;
    classDef kvs fill:#fee2e2,stroke:#dc2626;
    classDef doc fill:#fae8ff,stroke:#a21caf;
    classDef olap fill:#dcfce7,stroke:#16a34a;
    classDef other fill:#f0f9ff,stroke:#0369a1;
    class DATA root;
    class RDB rdb;
    class KVS kvs;
    class DOC doc;
    class OLAP olap;
    class TS,SE,VEC other;

カテゴリ	強み	代表例
RDB（関係DB）	ACID整合性・JOIN・枯れている	PostgreSQL・MySQL
KVS（Key-Value）	超高速な単一キー参照	Redis・DynamoDB
ドキュメントDB	柔軟なスキーマ・JSON直接保存	MongoDB・Firestore
列指向DB（OLAP）	集計・分析が桁違いに速い	BigQuery・Snowflake
時系列DB	メトリクス・センサー値の蓄積	InfluxDB・TimescaleDB
検索エンジン	全文検索・ファセット検索	Elasticsearch・OpenSearch
ベクトルDB	類似検索・AI埋め込み	pgvector・Pinecone

早期の判定フロー

質問を上から順に判定していくと、自分のユースケースに最適な第一候補が1つ決まります。

ACID整合性必須?
  └ Yes → RDB（PostgreSQL）
  └ No  → 単一キーで超高速?
            └ Yes → KVS（Redis/DynamoDB）
            └ No  → スキーマが揺れる?
                      └ Yes → ドキュメントDB
                      └ No  → 大量データの集計分析?
                                └ Yes → 列指向DB（BigQuery/Snowflake）
                                └ No  → 類似検索・AI埋め込み?
                                          └ Yes → ベクトルDB（pgvector）
                                          └ No  → 全文検索?
                                                    └ Yes → OpenSearch
                                                    └ No  → 時系列DB

既定はPostgreSQL + 必要に応じてキャッシュ（Redis）の2段構えで9割のシステムはカバーできます。

RDB（関係データベース）

行と列で構造化したデータをSQLで扱う、最も伝統的かつ強力なデータストアです。ACID整合性（原子性・一貫性・独立性・永続性）が保証されており、金額計算や在庫管理のようなミスが許されない業務で鉄板の選択肢です。JOINで複数テーブルを組み合わせる柔軟性も他のDBの追随を許しません。

弱点は「水平スケール（サーバーを増やして性能を上げる）が難しい」点と、「スキーマ変更が重い」点ですが、クラウド時代のマネージドRDB（Aurora・Cloud SQL）はこれらをかなり解消しており、中規模以下ではRDB一択と言って差し支えありません。

メリット	デメリット
ACID整合性が堅牢	水平スケールが難しい
JOINで柔軟にデータ取得	スキーマ変更のコストが高い
標準SQLで学習資産が豊富	非構造化データは苦手
エコシステムが成熟	超大量データでは性能劣化

代表例：PostgreSQL・MySQL・SQL Server・Oracle

特段の理由がなければPostgreSQL。全文検索・JSON・地理情報まで標準搭載で、困る場面が極めて少ないです。

KVS（Key-Value Store）

キー1つから値を取り出す単純な構造に特化したDBです。検索もJOINもできない代わりに、1ミリ秒以下のレスポンスと無限に近い水平スケール性を持ちます。セッション情報・キャッシュ・ランキング・レート制限など、「大量のシンプルな参照」が発生する場面で威力を発揮します。

DynamoDBのような「メインDBとしても使えるKVS」もありますが、JOINやトランザクションの制約が厳しく、業務システムのメインDBには不向きです。多くの現場ではRDBのキャッシュ層としてRedisを併用するのが標準パターンです。

メリット	デメリット
超高速な読み書き	JOIN・複雑な検索不可
水平スケール容易	スキーマ制約が乏しい
実装がシンプル	複数キー跨ぎの整合性が困難
キャッシュとして優秀	メインDBには設計難度が高い

代表例：Redis・Memcached・DynamoDB

キャッシュ層にはRedis一択。メインDBとして使うならDynamoDBが選択肢ですが、設計は慎重に進めます。

ドキュメントDB

JSON形式のドキュメントをそのまま保存するDBです。スキーマを事前定義せず、レコードごとに違う構造でも格納できるため、仕様変更が多い初期フェーズや、構造が定まらないログデータの蓄積に向きます。アプリ側のオブジェクトをそのまま保存できる手軽さも魅力です。

一方、スキーマが曖昧になりがちでデータ品質の低下・JOINできず設計が難しくなるといった問題が出やすく、規模が大きくなるほど RDB の方が楽になるのが実情です。MongoDB 全盛の2010年代が過ぎ、現代は「PostgreSQLのJSONB（JSON Binary、高速にインデックス検索できるJSON保存型）で代替」するケースが増えています。

メリット	デメリット
スキーマレスで柔軟	データ品質が落ちやすい
JSONそのままで保存可	JOINが不得意
初期開発が速い	規模が大きいと破綻しやすい
階層データの表現が自然	ACID保証が限定的（製品による）

代表例：MongoDB・Firestore・CouchDB

現代はPostgreSQLのJSONB型で代用するのが主流。純粋なドキュメントDBの出番は減少傾向です。

列指向DB（OLAP）

分析クエリに特化した構造のDBです。行ではなく列単位でデータを格納するため、「1000万行の売上合計」のような集計処理が桁違いに速く（秒単位 → 数ミリ秒）、DWH（データウェアハウス）の中核として使われます。

業務DB（RDB）と分析DB（列指向）を併用し、ETL/ELT（Extract/Transform/Load、抽出・変換・ロード、データを別DBへ移送する仕組み）で業務DBから分析DBへデータを移すのが現代の基本構成です。RDBで分析を回すと業務側の性能が落ちるため、この分離が事実上の標準になっています。

メリット	デメリット
集計・分析が超高速	1レコード単位の更新は苦手
TB〜PBクラスまでスケール	リアルタイム更新に不向き
SQLで分析可能	初期コストが高い場合あり
カラム圧縮が効いてコスト安	OLTP用途には使えない

代表例：BigQuery・Snowflake・Redshift・ClickHouse

分析基盤はBigQueryまたはSnowflakeの二択。後発ClickHouseもコスト面で台頭中です。

時系列DB・検索・ベクトル

用途特化の新興カテゴリで、主役ではなく特定用途で採用するのが基本です。メインDBとして単独で使うケースは稀で、RDBや列指向DBの補完として導入します。

カテゴリ	用途	代表例
時系列DB	メトリクス・IoTセンサー・株価	InfluxDB・TimescaleDB・Prometheus
検索エンジン	全文検索・ログ検索・ファセット	Elasticsearch・OpenSearch
ベクトルDB	AI埋め込みの類似検索・RAG	pgvector・Pinecone・Weaviate

ベクトルDBは LLM（Large Language Model、大規模言語モデル）/ RAGの流行で一気に台頭した領域で、既存DBの拡張（pgvector）から専用製品（Pinecone）まで選択肢が広がっています。

PostgreSQL拡張（pgvector等）で代用可能な範囲は、新たにベクトルDBを導入しない方が良いです。1DBで済む利点は大きいです。

判断基準

① データの性質

データの性質	向くカテゴリ
構造化・関係性あり（取引・顧客）	RDB
単純なキー参照（セッション・キャッシュ）	KVS
柔軟なJSON構造（ログ・設定）	RDBのJSONB or ドキュメントDB
大量の集計・分析	列指向DB（DWH）
時刻で並ぶ連続データ	時系列DB
全文検索・スコアリング	検索エンジン
AI埋め込みベクトル	ベクトルDB

既定はRDB + 必要に応じて補助DBの構成が最も安全です。「RDBで足りない部分だけ専用DBを足す」アプローチが実務では最適です。

② 規模とスケール

規模	典型構成
小規模（〜100万レコード）	RDBのみ
中規模（〜数億レコード）	RDB + Redis（キャッシュ）
大規模（数十億〜）	RDB + Redis + 列指向DW
超大規模（多地域・多ペタ）	RDB + KVS + 列指向 + 検索 + 時系列

「最初から多DBは過剰設計」ですが「規模が見えているのにRDBだけは不足」という両方向のミスマッチを避ける判断が必要です。

③ チームスキル

データストアは運用が極めて重要です。誰も運用できないDBは導入してはいけないのが鉄則で、チームが慣れていないDBを導入すると障害時に復旧できず、ビジネス継続が危険に晒されます。

PostgreSQL と MySQL は「知ってる人がたくさんいる」意味で鉄板です。新興DB（CockroachDB・Neon・PlanetScale等）は魅力的な機能を持ちますが、「採用実績と社内スキルを天秤にかけて決める」必要があります。

「チームが運用できるか」が技術選定の第一基準。Netflixが使っているからといって真似はできません。

ケース別の選び方

個人開発・小規模SaaSのMVP

PostgreSQL単体。JSONB・全文検索・地理情報まで一発で済み、専用DBを足す必要が極めて少ないです。マネージドなら Supabase・Neon・RDS の選択肢が豊富です。

中規模業務アプリ（SaaS・社内システム）

PostgreSQL + Redis。メインデータはRDBで整合性を担保し、セッションとキャッシュはRedisで速度を確保します。この構成で数百万ユーザーまで耐えられます。

BtoCで全文検索が重要（ECサイト・求人サイト）

PostgreSQL + Redis + Elasticsearch/OpenSearch。商品検索・絞り込みは専用エンジンに任せます。RDBのLIKE検索では規模に応じて遅くなっていきます。

分析ダッシュボードが重要（BI・KPI管理）

業務DB（RDB）+ 分析DB（BigQuery/Snowflake）。業務DBを直接分析すると性能が落ちるため、ETL/ELTで分析DBへ移します。小規模なら PostgreSQL のリードレプリカで代用も可能です。

AI / RAGを組み込む（チャットボット・検索強化）

PostgreSQL + pgvector が最速ルート。規模が大きければ Pinecone・Weaviate 等の専用ベクトルDBを検討します。Redis も Vector Search に対応しています。

IoT / メトリクス大量投入

TimescaleDB（PostgreSQL拡張）または InfluxDB。RDBに時系列大量投入はアンチパターンです。

データ量・アクセスパターン別の選定段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

データストアは「推測で選ぶ」のは負け筋です。データ量とRPS（Requests Per Second）で機械的に絞るのが実務の定石です。

データ量	書き込みRPS	読み取りRPS	メインDB	補助構成
〜1GB / 100万行	〜10	〜100	PostgreSQL単一	なし
〜100GB / 1000万行	〜100	〜1,000	PostgreSQL + Redis	—
〜1TB / 10億行	〜1,000	〜10,000	Aurora + Redis + OpenSearch	DWH検討
〜10TB / 100億行	〜10,000	〜100,000	Aurora + DynamoDB + ClickHouse	Kafka
10TB〜 / 100億行〜	10,000〜	100,000〜	DynamoDB / Spanner / Cassandra	完全分散基盤

テーブル行数の数値Gate：1000万行でインデックス設計の見直し、1億行でパーティション検討、10億行でシャーディング検討、100億行でNoSQL選択肢が現実的。データ量が見えないうちから分散構成を組むのは典型的な過剰設計です。

悩んだらPostgreSQL単一 → キャッシュ追加 → レプリカ追加 → シャーディングの順で拡張します。

筆者メモ — 「スキーマレスで速く」の代償

2017年初頭、認証設定を忘れたまま「インターネットに晒された数万件のMongoDBインスタンス」が一斉にランサム攻撃され、データを消されて身代金を要求される事件が発生しました。MongoDB 自体の欠陥というより、「スキーマレスで速く作れる」という触れ込みで深い理解なく本番に出されていた構成が、セキュリティ設定を置き去りにした結果だと当時から指摘されています。

別の話として、2010年代に流行した「MongoDB + Node.js」スタックで数年分の業務データを運用していた会社が、分析用途で使おうとした時に「フィールド名が時期によって別物・型が揺れる・配列とスカラが混在」していて、ほぼ全件の再加工に半年をかけた、という事例もしばしば語られます。PostgreSQLのJSONB型で型を縛りながら受けていれば避けられた工数です。

筆者も2018年頃、同僚が「MongoDBにしとけばとりあえず速い」と言って立てたサービスが、1年後に集計レポートが必要になった瞬間に地獄を見る様子を横目で見ていました。スキーマレスで速く作れるの代償は、運用・セキュリティ・分析の全方面で跳ね返ってくる。この教訓が2020年代のPostgreSQL再評価の下地になりました。

迷ったらPostgreSQLマネージド + PITR + マルチAZ。この3点セットで9割の事故は防げます。

データストア選定・運用の鬼門

データストア領域で事故る典型を整理します。One-way Doorの最たる領域なので、失敗すると取り返しがつきません。

禁じ手	なぜダメか
「スキーマレスで楽」でMongoDBを主DB採用	1年後に集計・Joinが必要になり、PostgreSQL再移行で3ヶ月消える
DBをデフォルト設定（認証なし）で本番運用	2017年初頭のMongoDBランサム攻撃（数万件被害）と同じパターン
画像・動画をDB本体に保存	DB肥大化、バックアップ時間爆発。S3 + URL参照が鉄則
NoSQLを強整合が必要な業務に採用	決済・在庫・会計で不整合、返金・信用失墜
自前でDBをシャーディング実装	運用負荷と学習コストで現場が溶ける。マネージドのAurora/Spannerで済ませる
バックアップを取るだけで戻す訓練なし	GitLab 2017年1月の事件と同じ顛末。四半期1回のリストア訓練
DBを単一AZで本番運用	AZ障害で全停止。マルチAZは本番の最低ライン
PostgreSQLのUUID v4を主キーに大量挿入	インデックス局所性が悪化、挿入性能が数倍遅く。UUID v7（2024年RFC化）へ
PITR（Point-in-Time Recovery）を無効化運用	誤操作で数時間分のデータ喪失。マネージドDBのPITRは必ず有効
マネージド版があるのに自前EC2で運用	セキュリティパッチ・バックアップ・フェイルオーバーで人件費が跳ねる

2017年初頭のMongoDB大規模ランサム攻撃（認証なしで公開された MongoDB / Redis / Elasticsearch が世界規模で暗号化・削除された事件）は、デフォルト設定を疑わず本番投入の代償の大きさを示しました。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、データストアはAIが理解しやすい・操作しやすいことが決定的な選定基準になります。SQL・型定義・スキーマ明示が揃ったRDBは、AIにとって最も扱いやすいDBで、AI時代にむしろ評価を上げています。

AI時代に有利	AI時代に不利
PostgreSQL（pgvector含む全部入り）	マイナーな新興DB（学習データ薄い）
標準SQL・明示的なスキーマ	スキーマレスの雑なJSON
マネージド（Supabase・Neon・RDS）	自前運用の独自DB
BigQuery・Snowflake（標準SQL）	独自クエリ言語のDB

AIエージェントがDBを直接操作する時代（Text-to-SQL・MCP（Model Context Protocol、AIとツールを繋ぐ標準プロトコル）経由のDB操作）には、「スキーマが整ったRDB」が最強の選択肢です。主流でないDBを選ぶとAIの生成精度が落ちます。

「PostgreSQL中心の設計」が、AI時代の事実上の標準解です。

よくある勘違い

• NoSQLの方がスケールする → 現代のPostgreSQLは数TB・数千QPSなら余裕で捌けます。NoSQLが必要な規模は、想像よりずっと大きいです
• MongoDBは最新でモダン → MongoDB全盛期は2010年代。現代は多くの現場でPostgreSQLのJSONB型に置き換わっています。「スキーマレスで速い」は運用・セキュリティ・分析のすべてで代償を払います
• 用途ごとに専用DBを並べるのが最適解 → 複数DBは運用コストが急上昇します。1つで足りるなら1つで済ませるのが常に最善
• SQLは時代遅れ → むしろAI時代に再評価されています。型が明確でAIが読み書きしやすく、Text-to-SQL/MCPで主戦場になっています

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• メインDBは何にするか（PostgreSQL / MySQL / その他）
• キャッシュは導入するか（Redis・Memcached）
• 分析DBは導入するか（BigQuery・Snowflake）
• 全文検索は必要か（Elasticsearch・OpenSearch）
• ベクトル検索は必要か（pgvector・Pinecone）
• マネージドサービスを使うか（自前運用はほぼ非推奨）
• バックアップとリストアの方針

最終的な判断の仕方

データストア選定の核心はOne-way Doorであるという意識を持つことです。アプリケーションのコードは書き直せますが、稼働中のDBを別DBに移行するのは事実上作り直しに近く、クラウドベンダー越えはさらに困難になります。だからこそ「迷ったらRDB」という保守的な出発点が多くの場合で正解になり、「例外条件が明確に見えた時だけ専用DBを足す」という判断の軸が安全です。運用できないDBは導入しない — チームが復旧できないDBは障害時にビジネスを止めてしまいます。

決定的な軸はAIが扱いやすいかどうかです。Text-to-SQLやMCP経由でAIエージェントが直接DBを操作する時代、標準SQLと明示的なスキーマを持つPostgreSQLは学習データも豊富で、AIの生成精度が圧倒的に高くなります。マイナーな新興DBや独自クエリ言語のDBは、AI時代にむしろ不利な選択になります。

選定の優先順位

1. 迷ったらPostgreSQL — JSONB / pgvector / 全文検索まで全部入りで、例外条件に当たるまでは1DBで足りる
2. チームが運用できるか — 知ってる人が多いDBを選ぶ。Netflix事例は参考にしない
3. 用途特化は例外条件で足す — Redis・検索・分析DBは「RDBで不足」が見えてから追加
4. マネージドを最優先 — 自前運用はほぼ非推奨、Supabase / Neon / RDSで運用負荷を下げる

「PostgreSQL中心 + 必要に応じて補助DB」これが現代の事実上の標準解です。

まとめ

本記事はデータストア選定について、RDB・KVS・ドキュメント・列指向・時系列・検索・ベクトルDBの強み弱み・データ量×用途別の段階表・AI時代に有利な選択肢まで含めて解説しました。如何だったでしょうか。

迷ったらPostgreSQL、用途特化は例外条件で足す、マネージドを最優先する。これが2026年のデータストア選定の現実解です。

次回はデータモデリング（テーブル設計・正規化・主キー・インデックス）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。