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

本記事について

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

本記事の問いは「このアプリにはどのDB種が適するか」です。RDB／KVS／ドキュメント／列指向／時系列／検索／ベクトルの各強み弱みと、データ量×用途別の段階表を提示します。システム全体の配置方針は別記事「システムアーキテクチャ」のデータストア記事に委ねます。

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

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

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

工具箱を想像してください。ネジを締めるならドライバー、釘を打つならハンマー、木を切るならノコギリ──1つの万能工具では全ての作業に対応できません。データベースも同じで、「正確な取引記録」ならRDB、「大量アクセスへの高速応答」ならKVS、「全文検索」なら検索エンジンと、用途によって最適な道具が違います。

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

もし選定を間違えたらどうなるか。速度が出ない・スケールしない・開発効率が落ちるという根本的な問題に直結し、しかも一度運用が始まるとデータ移行は極めて高コストで、後から変えるのは現実的に不可能に近い判断です。データストアは全てのアプリケーション設計の土台で、DBが決まらないとエンティティ設計・API設計・トランザクション境界の全てが決まりません。

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

主要な分類と早期判定フロー

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

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

各カテゴリの使いどころ

RDB ― 中規模以下では一択

ACID整合性が保証され、金額計算や在庫管理のようなミスが許されない業務で鉄板です。弱点だった水平スケールとスキーマ変更の重さも、マネージドRDB（Aurora・Cloud SQL）がかなり解消しました。特段の理由がなければPostgreSQLです。全文検索・JSONB・地理情報・pgvectorまで標準搭載で、困る場面が極めて少ない。

KVS ― キャッシュ層の定番

キー1つから値を取り出す構造に特化し、1ミリ秒以下のレスポンスと水平スケール性を持ちます。セッション・キャッシュ・ランキング・レート制限が主戦場で、キャッシュ層にはRedis一択です。DynamoDBはメインDBとしても使えますが、JOINやトランザクションの制約が厳しく、業務システムのメインには不向きです。

ドキュメントDB ― JSONBで代替が主流

JSON形式のままスキーマレスに格納でき初期開発は速いのですが、データ品質が落ちやすく、規模が大きくなるほどRDBの方が楽になります。MongoDB全盛の2010年代が過ぎ、現代は「PostgreSQLのJSONB型で代替」するのが主流で、純粋なドキュメントDBの出番は減少傾向です。

列指向DB ― 分析はBigQuery / Snowflakeの二択

列単位でデータを格納するため、「1000万行の売上合計」のような集計が桁違いに速いDBです。業務DB（RDB）と分析DB（列指向）を分け、ETL/ELTでデータを移すのが現代の基本構成です。分析基盤はBigQueryまたはSnowflakeの二択で、コスト面でClickHouseも台頭中です。

時系列・検索・ベクトル ― 特定用途で足す補完役

時系列DB（TimescaleDB・InfluxDB）はメトリクス・IoT用、検索エンジン（OpenSearch）は全文検索・ログ検索用、ベクトルDB（pgvector・Pinecone）はRAG・類似検索用です。いずれも主役ではなく「RDBで不足」が見えてから足すのが基本で、pgvector等のPostgreSQL拡張で代用できる範囲は新たなDBを立てない方が良いです。1DBで済む利点は大きい。

どう選べばいいのか ― データ量×用途の段階表

※ 2026年4月時点の業界相場値です。

「推測で選ぶ」のは負け筋です。データ量とアクセス量で機械的に絞ります。

行数の数値Gateは、1000万行でインデックス設計の見直し、1億行でパーティション検討、10億行でシャーディング検討です。データ量が見えないうちから分散構成を組むのは典型的な過剰設計で、悩んだらPostgreSQL単一 → キャッシュ追加 → レプリカ追加 → シャーディングの順で拡張します。

3つのシナリオで考える

個人開発・スタートアップの場合

この規模であれば、PostgreSQL単体（SupabaseやNeon、RDSの最小構成）に、画像や動画だけS3へ置く構成で十分だと思います。正直なところ、Redisすら最初は要りません。1000万行・100GBくらいまではこの構成のままで戦えてしまいますので、MVPの段階で分散構成を組むのは典型的な過剰設計と言えるでしょう。

個人・スタートアップ ― 1か月で出せる構成が正解 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-startup/

中小SaaSの場合

PostgreSQL（AuroraやCloud SQL）にRedisを足した構成で、数百万ユーザーまでは耐えられると考えています。全文検索が重要なECや求人サイトならOpenSearchを、BIダッシュボードを重視するならBigQueryやSnowflakeを足すことになりますが、いずれも要件が実際に出てきた時点で足すのがコツです。先回りで入れたくなる気持ちは分かりますが、大抵は使われないまま運用コストだけが残ってしまいます。

中小SaaS ― マネージドに寄せて少人数で回す ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-saas/

大企業の場合

10TB超・100億行級になって初めて、DynamoDBやSpanner、Cassandraのような完全分散構成が視野に入ってきます。とは言っても、キャッシュ→レプリカ→パーティションという段階を踏んだ先の話ですので、いきなり飛びつくものではありません。この規模では監査要件（履歴保持・アクセスログ）もデータストア選定の条件に含める必要が出てきます。

大企業基幹系 ― 新しい技術より組織で成立する設計 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-case-enterprise/

なおAI / RAG組み込みはPostgreSQL+pgvectorが最速ルート、IoT・メトリクス大量投入はTimescaleDBという特化解もあります。全ケース共通で、誰も運用できないDBは導入してはいけないのが鉄則です。

AI判断軸 ― PostgreSQLがAI時代の安全牌になった

AIの生成精度は学習データ量に直結する

AIが生成するSQLの精度は対象DBの学習データ量で決まります。PostgreSQLは利用事例が膨大で、AIが生成するSQLの正確性が他DBより高い。さらにpgvector（ベクトル検索）・pg_trgm（全文検索）・JSONB（ドキュメント格納）で用途特化DBの役割を1インスタンスで兼ねられます。DB数が増えるほどAIがコンテキストを把握しにくくなるため、「1DB完結」できるPostgreSQLの全部入り戦略はAI時代に合理的です。

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

AIがクエリを生成する際、RDBではテーブル定義（CREATE TABLE文）がそのままコンテキストとして使えます。スキーマレスDBでは同じコレクション内でドキュメント構造が異なることがあり、AIは「どのフィールドが必ず存在するか」を判断できず、実行時エラーになるコードを生成するリスクが常にあります。ZodやJSONスキーマで構造を明示すれば緩和できますが、それなら最初からCREATE TABLE文で表現したほうが簡潔で、スキーマレスを選ぶ積極的な理由は以前より減っています。

やってはいけないこと

One-way Doorの最たる領域なので、失敗すると取り返しがつきません。特に危険な6つに絞ります。

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

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

別の話として、MongoDB+Node.jsスタックで数年分の業務データを運用していた会社が、分析用途で使おうとした時に「フィールド名が時期によって別物・型が揺れる・配列とスカラが混在」していて、ほぼ全件の再加工に半年をかけた事例もしばしば語られます。スキーマレスで速く作れるの代償は、運用・セキュリティ・分析の全方面で跳ね返ってくる。この教訓が2020年代のPostgreSQL再評価の下地になりました。

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

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

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

決定理由の残し方

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

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

この記事に関連する記事

まとめ

本記事はデータストア選定について、各カテゴリの強み弱み・データ量×用途別の段階表・AI時代に有利な選択肢まで含めて解説しました。如何だったでしょうか。

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

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

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

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

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