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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。

そもそもデータストア選定とは何か

データストア選定とは、ざっくり言えば「このアプリのデータをどの種類のデータベースに預けるかを決めること」です。

工具箱を想像してください。ネジを締めるならドライバー、釘を打つならハンマー、木を切るならノコギリ──1つの万能工具では全ての作業に対応できません。データベースも同じで、「正確な取引記録」ならRDB、「大量アクセスへの高速応答」ならKVS、「全文検索」なら検索エンジンと、用途によって最適な道具が違います。現代のアプリは複数のデータストアを組み合わせて使うのが当たり前で、その選び方がアプリ全体の速度・拡張性・開発効率を左右します。

この記事の守備範囲

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

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

なぜデータストア選定が重要なのか

もしデータストア選定を間違えたらどうなるか。選択を誤ると速度が出ない・スケールしない・開発効率が落ちるといった根本的な問題に直結します。しかも一度運用が始まるとデータ移行は極めて高コストで、後から変えるのは現実的に不可能に近い判断です。

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

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

主要な分類

早期の判定フロー

質問を上から順に判定していくと、自分のユースケースに最適な第一候補が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一択と言って差し支えありません。

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

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

KVS（Key-Value Store）

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

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

代表例：Redis・Memcached・DynamoDB

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

ドキュメントDB

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

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

代表例：MongoDB・Firestore・CouchDB

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

列指向DB（OLAP）

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

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

代表例：BigQuery・Snowflake・Redshift・ClickHouse

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

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

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

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

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

判断基準

① データの性質

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

② 規模とスケール

「最初から多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）で機械的に絞るのが実務の定石です。

テーブル行数の数値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の最たる領域なので、失敗すると取り返しがつきません。

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

AI判断軸

選定の優先順位

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

PostgreSQLがAI時代の「安全牌」になった構造的理由

AIコーディングツールが生成するSQLの精度は、対象DBの学習データ量に直結します。PostgreSQLはオープンソースで利用事例が膨大なため、Stack Overflow・GitHub・公式ドキュメントの情報が圧倒的に豊富です。結果として、AIが生成するPostgreSQL向けSQLは他のDBと比較して正確性が高くなります。

さらにPostgreSQLはpgvectorでベクトル検索、pg_trgmで全文検索、JSONBでドキュメント格納と、用途特化DBの役割を1つのインスタンスで兼ねられます。DB数が増えるほど運用の複雑さが増し、AIがコンテキストを把握しにくくなるため、「1DB完結」できるPostgreSQLの全部入り戦略はAI時代に合理的です。

マイナーなDBや独自クエリ言語を持つDBは学習データが少ないため、AIの生成精度が落ちます。「技術的に面白い」という理由だけでニッチDBを選ぶと、AI活用の恩恵を受けられなくなる点を選定時に意識してください。

スキーマレスDBがAI活用を阻害するメカニズム

MongoDBのようなスキーマレスDBは柔軟性が魅力ですが、AI活用の観点では不利に働きます。AIがクエリを生成する際、テーブル定義（CREATE TABLE文）がそのままコンテキストとして使えるRDBに対し、スキーマレスDBではドキュメント構造を別途説明する必要があります。

実際の問題として、スキーマレスDBでは同じコレクション内でドキュメント構造が異なることがあり、AIは「どのフィールドが必ず存在するか」を判断できません。存在しないフィールドへのアクセスが実行時エラーになるコードを生成するリスクが常にあります。

対策としては、スキーマレスDBを使う場合でもZodやJSONスキーマでドキュメント構造を明示的に定義し、その定義ファイルをAIのコンテキストに含める運用が有効です。ただし、それなら最初からRDBのCREATE TABLE文で表現したほうが簡潔であり、スキーマレスを選ぶ積極的な理由は以前より減っています。

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

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

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

決定理由の残し方

データストアの選定は一度決めるとデータ移行コストが大きく、簡単にはやり直せません。なぜそのデータストアを選んだかを ADRで記録しておくことが、将来の見直し判断を支えます。

ADR はスプレッドシートや Wiki ではなく、コードリポジトリの docs/adr/ に Markdown で管理するのがベストです。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADR の最大の価値です。

この記事に関連する記事

https://senkohome.com/arch-intro-data-etl/ https://senkohome.com/arch-intro-data-overview/ https://senkohome.com/arch-intro-data-platform/

まとめ

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

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

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

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

本記事で扱った内容の詳細は PostgreSQL 公式サイト も合わせて参考にしてください。

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