TL

Cloud Service

データベース

Azure の DB の選び方。リレーショナルか、NoSQL か、キャッシュか、分析(DWH)か。要件から逆引きで即断する早見表。

基礎
最終更新: 2026-06-04

要件から逆引き

要件選ぶもの
一般的なリレーショナルDB(SQL/JOIN)Azure SQL Database
100TB級・高速バックアップ・読み取りスケールAzure SQL Database Hyperscale
OS/SQL Server を細かく制御したい(ほぼ完全互換)Azure SQL Managed Instance
超低遅延・グローバル分散のサーバーレスNoSQLAzure Cosmos DB
読み取りを高速化するキャッシュAzure Cache for Redis
大量データの集計・分析(DWH)Azure Synapse Analytics / Microsoft Fabric
OSS互換(PostgreSQL/MySQL)で動かしたいAzure Database for PostgreSQL / MySQL

リレーショナルの選択肢を整理

Azure のリレーショナルは「マネージドの度合い」と「互換性」で分かれます。

観点Azure SQL DatabaseSQL Managed InstanceSQL on Azure VM
位置づけPaaS(DBが単位)PaaS(インスタンスが単位)IaaS(自前運用)
SQL Server互換高い(一部機能制限)ほぼ完全(SQL Agent等も可)完全(OS まで自由)
運用負荷最小(パッチ/バックアップ自動)大(OS・パッチも自分)
ネットワーク分離Private EndpointVNet 注入が前提VNet 内に配置
向き新規・クラウドネイティブオンプレ移行(リフト&シフト)OSレベルの要件がある時
まず Azure SQL Database から検討

新規開発なら、最も PaaS 寄りで運用が楽な Azure SQL Database が第一候補。 オンプレの SQL Server を「ほぼそのまま」上げたいなら Managed Instance、OS や特殊機能まで触りたいときだけ SQL on VM を選びます。

詳細比較(リレーショナル vs NoSQL)

観点Azure SQL DatabaseHyperscaleCosmos DB
モデルリレーショナルリレーショナル(高スケール)NoSQL(複数API)
スケール縦+読み取りレプリカストレージ最大100TB・最大30レプリカ水平・ほぼ無限・自動(RU)
可用性ゾーン冗長/フェイルオーバーグループページサーバ分散・高速FO複数リージョン・マルチマスター可
クエリ柔軟なT-SQL/JOIN柔軟なT-SQL/JOINキー中心(API依存・JOINは限定)
課金単位DTU または vCorevCoreRU/s(プロビジョン or サーバーレス)
整合性強整合(ACID)強整合(ACID)5レベルから選択(既定:セッション)
向き汎用RDB・既存資産大規模RDB・急成長超低遅延・グローバル・大量書き込み

Cosmos DB の API はどれを選ぶ?

Cosmos DB は1サービスで複数の API を持ちます。新規なら NoSQL、移行なら既存資産に合わせます。

API中身/互換選ぶ場面
NoSQL (Core)ドキュメント(独自・最も機能が新しい)新規開発の既定
MongoDBMongoDB ワイヤプロトコル互換既存 MongoDB アプリの移行
CassandraCQL 互換(ワイドカラム)既存 Cassandra の移行
Gremlinグラフ関係/つながりを辿る用途
TableAzure Table 互換(キーバリュー)Table Storage からの移行/高機能化

迷ったら

  • JOINや複雑なT-SQLが要る → Azure SQL Database(100TB級や急成長なら Hyperscale
  • オンプレ SQL Server をほぼそのまま移行 → SQL Managed Instance
  • キー引きで超低遅延・グローバルに青天井スケール → Cosmos DB
  • DBの前にキャッシュして高速化/負荷軽減・セッション保持 → Azure Cache for Redis
  • TB級を集計・BI → Azure Synapse Analytics / Microsoft Fabric
  • PostgreSQL / MySQL のまま動かしたい → Azure Database for PostgreSQL / MySQL
課金モデルの勘所
  • Azure SQL は DTU(バンドル)か vCore(CPU/メモリを個別指定・Hybrid Benefit 可)。本番は vCore が基本。
  • Cosmos DB は RU/s(要求ユニット)で課金。安定負荷はプロビジョニング、まばらな負荷はサーバーレスが有利。
設計で詰まりやすい点
  • Cosmos DB は パーティションキー設計が性能と課金を左右する。偏ると「ホットパーティション」で詰まる。
  • Cosmos DB の既定整合性はセッション。強整合が要るかをアプリ要件から判断する。
  • リレーショナルの可用性はゾーン冗長+フェイルオーバーグループで確保。リードレプリカは読み取りスケール用と役割を分けて考える。
アンチパターン

NoSQL が要らないのに「速そうだから」で Cosmos DB を選び、JOIN や集計で苦しむのは典型的な失敗。 関係データ・複雑クエリはリレーショナル(Azure SQL)超低遅延・大量・キー引きは Cosmos DB と用途で割り切る。

AWS との対応(早見)

役割AzureAWS
マネージド RDBAzure SQL DatabaseAmazon RDS
高スケール RDBAzure SQL Database HyperscaleAmazon Aurora
サーバーレス NoSQLAzure Cosmos DBAmazon DynamoDB
インメモリキャッシュAzure Cache for RedisAmazon ElastiCache
データウェアハウスAzure Synapse AnalyticsAmazon Redshift
OSS RDB(PostgreSQL/MySQL)Azure Database for PostgreSQL/MySQLAmazon RDS / Aurora

関連: Azure SQL Database / Hyperscale / Cosmos DB

Azure Service

データベースを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

cheatsheets

比較で見る軸

クラウド: Azure / カテゴリ: cheatsheets / 難易度: basic

導入後に効く点

導入後の運用手順、権限、監視、更新方法まで含めて評価します。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
cheatsheets
難易度
basic
関連資格
設計柱

判断チェックリスト

  • 自社の用途が「cheatsheets」に近いか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

cheatsheets