本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第6弾として、データストアの全体配置方針について解説する記事です。
RDBMS・NoSQL・キャッシュ・検索エンジン・オブジェクトストレージを「何をどこに置くか」という視点で整理し、システム全体の配置をどう決めるかを扱います。個別アプリでの詳細な選定フローやテーブル設計、分析基盤の構築は、別カテゴリ「データアーキテクチャ」の記事に委ねます。
本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。
この記事の結論
- 迷ったらPostgreSQL単一構成から始める
- 足す順序はキャッシュ（Redis）→ レプリカ → 検索（OpenSearch）→ シャーディング
- 画像・動画は最初からS3へ。RDBMSに入れない
- スキーマ変更はマイグレーションツール+段階適用で行う
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもデータストアとは何か
データストアとは、ざっくり言えば「アプリケーションが扱うデータを保管・取り出しする仕組みの総称」です。
図書館を想像してください。書籍は本棚（RDBMS）に整然と並べ、よく参照される辞典はカウンター横（キャッシュ）に置き、ポスターや写真は別棟の倉庫（オブジェクトストレージ）に収めます。1か所に全部詰め込むと溢れるし探せない──用途ごとに最適な保管場所を選ぶのが、データストアの配置方針です。
なぜ配置方針が重要なのか
もしデータストアの配置を深く考えずに進めたらどうなるか。「とりあえず全部RDBMSに入れておこう」で始めたシステムが、半年後にアクセス集中でレスポンス10秒超え──慌ててキャッシュを足そうにも、アプリのデータアクセス層を丸ごと書き直す羽目になります。逆に流行りに乗ってNoSQLを選んだら、後から「やっぱりJOINが必要だった」と気づいても、数千万件のデータ移行は数日〜数週間のダウンタイムを伴います。
データストアの選定は、システムアーキテクチャの中で最も後戻りが困難な判断です。アプリのコードは書き直せても、スキーマと大量データが積み上がった後のDB移行は桁違いに重く、ここで何を選んだかが向こう5〜10年を左右します。
主な4カテゴリ
データストアは用途別に4つのカテゴリに大別できます。それぞれ得意な用途が異なるため、1つのシステム内で複数を組み合わせるのが現代の主流です。
| カテゴリ | 得意なこと | 代表例 |
|---|---|---|
| RDBMS | 構造化データ・整合性重視 | PostgreSQL・MySQL |
| NoSQL | スケール重視・柔軟スキーマ | DynamoDB・MongoDB |
| キャッシュ | 高速アクセス・一時データ | Redis・Memcached |
| 検索エンジン | 全文検索・集計 | Elasticsearch・OpenSearch |
加えてオブジェクトストレージ（S3等）が画像・動画・添付ファイルの保管先として使われます。
それぞれの使いどころ
RDBMS ― まずここから
RDBMS は、データを表（テーブル）形式で管理し、SQLで操作する伝統的なデータベースです。ACIDトランザクションによる強整合性を保証し、金融・業務アプリなどデータの正確性が絶対に必要な領域で圧倒的な実績があります。
新規案件で特別な理由がない限り、第一候補はPostgreSQLです。JSON型・全文検索・GISなど多機能さがOSSの中で突出しており、後述するベクトル検索（pgvector）まで1つでカバーできます。AWS上ならPostgreSQL互換のAmazon Auroraが運用面で有力です。ほかにMySQL/MariaDB（既存Webサービスとの互換）・Oracle/SQL Server（既存の基幹系・Microsoft環境）もありますが、いずれも「既にそれを使っている」事情がある場合の選択肢です。
NoSQL ― スケールが必要になってから
NoSQL はRDBMS以外のデータベース全般を指し、基本思想は「RDBMSの整合性を一部犠牲にしてでもスケールさせたい」です。実務でよく使うのは次の2つです。
DynamoDB（AWS製）はフルマネージドの分散KVSで、理論上無限にスケールし、高トラフィックAPIやサーバーレス構成で本領を発揮します。ただしJOINや集計が苦手で、「先にアクセスパターンを決めてからテーブルを設計する」というRDBMSと逆の発想が必要です。
Redis はインメモリキャッシュのデファクトスタンダードです。ミリ秒未満のレスポンスを活かして、セッション管理・ページキャッシュ・レート制限・ランキングなど「速さが命の一時データ」を一手に引き受けます。
ほかにドキュメント型（MongoDB）・ワイドカラム型（Cassandra）・グラフ型（Neo4j）の系統がありますが、それぞれ階層データ・時系列大量書き込み・関係分析という明確な用途が出てから検討すれば十分です。整合性が命の業務アプリでNoSQLをメインに据えるのは筋が悪い選択です。
検索エンジン ― LIKE検索が遅くなったら
検索エンジンは、文章や商品説明などテキストの中身を素早く検索する専用DBです。RDBMSでも LIKE '%キーワード%' は書けますが、数万件を超えると実用になりません。
本格的な検索とログ集約まで見据えるなら Elasticsearch / OpenSearch がデファクトです。一方、小規模ならPostgreSQLの全文検索（pg_bigm等）で追加DBなしに始められます。ほかにMeilisearch（軽量・モダン）やAlgolia（マネージドSaaS）もあり、規模と運用体制で選びます。日本語検索では形態素解析（Kuromoji）の設定が鍵で、辞書が不適切だと「東京都」が「東京」と「都」に分解される検索漏れが連発します。
オブジェクトストレージ ― ファイルはDBに入れない
オブジェクトストレージは、画像・動画・PDFなどのファイルを保管する専用ストレージです。RDBMSに画像を直接入れるとDBが肥大化して性能が落ちるため、「メタデータはRDBMS、実体はオブジェクトストレージ」という分離が基本です。
デファクトはAmazon S3で、CDN（CloudFront等）と組み合わせると配信の高速化とコスト削減が同時に効きます。帯域課金のないCloudflare R2（S3互換）は、動画配信など帯域コストが支配的な用途で有力な代替です。
Polyglot Persistence ― 組み合わせが前提
用途ごとに最適なデータストアを組み合わせて使う設計思想を Polyglot Persistence（多言語永続化）と呼びます。「1つのDBで全部」は設計としては綺麗に見えますが、性能・コスト・運用性のバランスでは用途別の分業構成が勝ち、ECサイトやSaaSプロダクトではこれがほぼ標準です。
分業させたデータストア同士は同期的に連携させず、非同期メッセージキュー（SQS/Kafka等）でつなぐのが障害耐性の観点でも筋のいい設計です。同期で繋ぐと、1つのDBが落ちた瞬間に連鎖停止が起きます。
どう選べばいいのか ― 規模別の3シナリオ
配置方針は「自分のプロジェクトの規模」で決まります。典型的な3つのケースで考えてみます。
個人開発・スタートアップなら ― PostgreSQL+S3だけ
1〜5人・予算ほぼゼロなら、PostgreSQL（Supabase / RDS最小構成）とS3の2つだけで始めるのが良いと思います。正直、Redisすら不要です。セッションはDBに置けば足りてしまいますし、この規模でキャッシュ層や検索エンジンを足すのは運用負担が増えるだけの過剰装備になってしまいます。マネージドの無料枠・最小プランで月数千円以内に収まりますよ。
中小SaaSなら ― マネージドで3点セット
チーム5〜30人・数万ユーザー規模なら、Aurora（またはCloud SQL）+ ElastiCache（Redis）+ S3が基本形です。読み取り負荷はまずキャッシュとリードレプリカで受け、商品検索・横断検索の要件が出た時点でOpenSearchを足します。全てマネージドに寄せ、DB運用の専任を置かずに回すのがこの規模の生命線です。
大企業・大規模トラフィックなら ― 分散を検討する規模かを先に測る
書き込みが秒間1万を超える、データが数十億行に達する──そこで初めてシャーディングやDynamoDB/Spannerのような分散DBが選択肢に入ります。逆に言えば、「その規模に本当に達しているか」を数値で確認する前に分散構成へ踏み込むのは典型的な過剰設計です。まずキャッシュとレプリカで粘り、移行するなら数か月がかりのプロジェクトとして計画します。
規模の目安
2026年4月時点の経験則を段階表にまとめます。自分のプロジェクトがどの行にいるかで、必要な構成が決まります。
| データ量の目安 | 推奨メインDB | 補助の典型構成 |
|---|---|---|
| 〜1000万行 | PostgreSQL 単一（+レプリカ1本） | Redis（セッション） |
| 〜10億行 | Aurora / Cloud SQL +レプリカ複数 | Redis + OpenSearch |
| 〜100億行 | Aurora +シャーディング or DynamoDB | Redis + Kafka |
| 100億行〜 | DynamoDB / Spanner / Cassandra | Kafka +データレイク |
1テーブル1,000万行を超えたらインデックスとパーティションの見直し、1億行でシャーディング検討、10億行でNoSQLが現実的な選択肢になる、というのが目安です。ただしDBを替える前に「キャッシュを足すだけで済まないか」の検証が先です。悩んだらPostgreSQL単一 → キャッシュ追加 → レプリカ追加 → シャーディングの順に進みます。
AI判断軸 ― データストア選定はどう変わるか
AI駆動開発が前提になると、選定軸に「AIがクエリやマイグレーションを正確に書けるか」が加わります。
SQLとAI生成精度の関係
AIにコードを書かせたとき、SQLの精度は他のクエリ言語と比べて圧倒的に高いです。50年の歴史で蓄積された膨大な学習データがあるためです。一方、DynamoDBのPartiQLやMongoDBの集約パイプラインは独自性が高く、AIが正しく書けないケースが頻繁に発生します。これは「NoSQLを使うな」という意味ではなく、AIにクエリを書かせる前提なら、アクセスパターンをTypeScriptの型で定義するなど、AIが正確に書ける足場を意図的に用意する必要がある、ということです。
ベクトルDBという新しい層
RAG（Retrieval-Augmented Generation）を使ったAI機能を組み込む場合、テキストをベクトル化して検索する層が必要になります。判断の分かれ目は「既存のPostgreSQLにpgvectorを足すか、専用DBを立てるか」です。ベクトル数が100万件以下ならpgvectorで十分で、余計な運用を増やさないのが正解です。それを超えて検索レイテンシが問題になったら、Pinecone・Qdrant等の専用DBへの分離を検討します。AI機能のロードマップがあるなら、pgvectorが使えるPostgreSQLを最初から選んでおくと移行が要りません。
スキーマをコードで管理する
AIはマイグレーションSQLの生成が得意ですが、それが機能するのは、スキーマ定義（Prisma / Drizzle / SQLマイグレーションファイル）がGitに入っていて、AIが過去の履歴とアプリコードを一緒に読める場合だけです。GUIでスキーマを管理していてコードに定義がない状態では、AIはマイグレーション支援ができません。スキーマのコード管理はもはや好みの問題ではなく、AI活用の前提条件です。
やってはいけないこと
データストアで「後から変えられない」事故の大半は、スキーマ変更と選定ミスから生まれます。特に危険な5つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 列のリネームを1回のマイグレーションで実施 | 旧コードが動いているインスタンスが即死する → expand/contract（列追加→両方書き込み→切替→旧列削除）で3回に分ける |
| 大テーブルへ通常の CREATE INDEX | テーブルがロックされ本番が書き込み不能になる → PostgreSQLは CREATE INDEX CONCURRENTLY、MySQLは gh-ost 等を使う |
| 「なんとなく」でNoSQLをメインに選ぶ | 後からJOIN・集計が必要になり再設計の大工事 → トランザクションが絡むなら悩んだらRDBMS |
| 画像・動画をRDBMSに直接格納 | DBが肥大化し性能・バックアップ時間が悪化する → メタデータはDB、実体はS3に分離する |
| リストア訓練なしのバックアップ運用 | 本番障害時に「戻せない」ことが判明する → RPO/RTOを決め、戻す訓練まで含めて運用する |
最後の項目は笑い話ではありません。2017年のGitLab DB削除事件では、エンジニアが本番と開発を取り違えて削除した際、用意していた5種類のバックアップが全て機能しませんでした。肝心なのは「取っているか」ではなく「戻せるか」です。
筆者メモ ― MongoDBの「なんとなく」事件
スタートアップが「スキーマを自由に変えたいから」という理由だけでMongoDBを選び、半年後に売上レポートの集計フェーズへ入った瞬間、JOINもトランザクションも欲しい仕様が次々に出てきて現場が止まった──という事例は一度ならず聞かれます。結局PostgreSQLへの移行に3ヶ月を溶かしたチームもあるといいます。私が2018年頃に見ていたMongoDB採用のスタートアップも、注文集計の要件が出た途端にクエリが書けず、BIツールのためにPostgreSQLへの日次同期を追加する羽目になりました。
教訓は、「DB選定は今の楽さではなく、1年後の要件で決める」ということです。「スキーマレスが楽」は、集計が始まるまでの話です。
決めるべきこと ― 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- メインDB（PostgreSQL / MySQL / Aurora / DynamoDB）
- キャッシュ戦略（Redis / Memcached / アプリ内 / CDN）
- 検索基盤（OpenSearch / PostgreSQL全文検索 / SaaS）
- ファイルストア（S3 / R2 / Blob Storage）
- バックアップ方針（RPO / RTO / 保管期間）
- スケール戦略（レプリカ / シャーディング / マルチリージョン）
言語化した答えはADR（Architecture Decision Record）として記録に残すと、数年後の「なぜMySQLではなくPostgreSQLなのか」という問いに一目で答えられます。ADRの書き方は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はシステムアーキテクチャレベルでのデータストア配置方針について、4カテゴリの使いどころ・Polyglot Persistence・規模別の選び方・スキーマ変更の鬼門まで含めて解説しました。如何だったでしょうか。
新規はPostgreSQL中心に、用途特化を必要最小限で足す（キャッシュにRedis、検索にOpenSearch、画像にS3）のが2026年の鉄板です。最初から多層構成を組むと運用が破綻するので、足りなくなってから足す順序が現実的です。
次回は「ネットワーク」（VPC・サブネット・CIDR設計）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS データベースサービス も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（17/95）