クラウドネイティブなアプリケーション、特にマルチテナントSaaSを開発する際、データベースの選択はアーキテクチャの根幹をなす重要な意思決定です。Azureは多様なリレーショナルデータベースサービスを提供しており、特にAzure SQL DatabaseとPostgreSQL系のサービスは多くの開発者を悩ませる選択肢となっています。
本記事では、これらのサービスのスケーラビリティ、コスト、設計思想、サポート体制などを多角的に比較し、どのような要件にどのサービスが最適なのかを明らかにします。
Azureが提供する主要RDBMSサービス
まず、比較対象となる主要なサービスを整理します。
- Azure SQL Database: Microsoftの看板RDBMSであるSQL ServerをPaaSとして提供。特にHyperscaleサービスレベルは、そのユニークなアーキテクチャで高いスケーラビリティを実現します。
- Azure Database for PostgreSQL - Flexible Server: オープンソースのPostgreSQLをマネージドサービスとして提供。コスト効率に優れ、シンプルなスケールアップが可能です。
- Azure Cosmos DB for PostgreSQL: PostgreSQLにCitus拡張を組み合わせ、水平分散（スケールアウト）を実現するサービス。もともとは「Hyperscale (Citus)」と呼ばれていましたが、現在はCosmos DBファミリーにブランド統合されています。
スケーラビリティの考え方：スケールアップ vs スケールアウト
各サービスのスケーラビリティの実現方法は大きく異なります。
1. スケールアップ（垂直スケーリング）
サーバーのCPUやメモリを増強して性能を向上させるアプローチです。
- PostgreSQL Flexible Server: このモデルの典型です。性能限界に近づいたら、より上位のSKUに変更することで対応します。
- Azure SQL Database: 同様にスケールアップが可能ですが、Hyperscaleという例外的な選択肢も存在します。
2. スケールアウト（水平スケーリング）
サーバーの台数を増やして負荷を分散させるアプローチです。実現方法によって、アプリケーション側の考慮事項が異なります。
透過的なスケールアウト
データベース側が分散を吸収してくれるため、アプリケーションは単一のデータベースとして接続できます。
-
Cosmos DB for PostgreSQL (Citus): 分散キー（例:
tenant_id）を基にデータをシャード化し、複数のワーカーノードに分散します。コーディネータノードがクエリを解析し、適切なワーカーに処理を振り分けるため、アプリケーションは接続先を意識する必要がありません。 - Azure SQL Database Hyperscale: データベースの内部アーキテクチャレベルでスケールアウトを実現します。コンピュートノードとは別に、データページを管理する「ページサーバー」が複数存在し、最大128TBという巨大なストレージを可能にしています。アプリケーションからは完全に透過的で、単一のデータベースにしか見えません。
アプリケーションレベルでのスケールアウト
アプリケーション側でデータの格納先データベースを切り替える必要があるアプローチです。
- Azure SQL Database + Elastic Pool: テナントごとにデータベースを分割（シャーディング）し、それらをリソース共有プールである「Elastic Pool」にまとめる構成です。アプリケーションは、どのテナントがどのデータベースに属するかを管理し、接続をルーティングする必要があります。Microsoftはこれを支援する「Elastic Database tools」を提供しています。
コスト比較：PostgreSQL系の優位性
小〜中規模構成において、コストはPostgreSQL系のサービスに大きな優位性があります。特に開発環境や小規模な本番環境を想定した場合、その差は顕著です。
注意： 最小スペック同士の比較は、性能特性が異なるため必ずしも公平ではありません。ここでは、ある程度の性能を担保する「2vCore」を基準に比較します。
月額コスト比較（2vCore基準、1ドル=150円換算の参考値）
| サービス | 月額目安 (USD) | 月額目安 (円) | 特徴 |
|---|---|---|---|
| PostgreSQL Flexible Server (General Purpose) | 約 $80 | 約 12,000円 | 最もコスト効率が良い選択肢。 |
| Cosmos DB for PostgreSQL (Single-node) | 約 $100 | 約 15,000円 | 将来のスケールアウトを見据えた初期投資として。 |
| Azure SQL Database (General Purpose) | 約 $350 | 約 52,500円 | ライセンス込みの価格。エコシステムとの親和性が高い。 |
| Azure SQL Database Hyperscale | 約 $800 | 約 120,000円 | 大容量・読み取り性能を求める場合に。高価。 |
このように、同等のvCore数で比較しても、PostgreSQL系のサービスはAzure SQL Databaseに比べて数分の一のコストで利用できることがわかります。
将来のスケールを見据えた設計上の考慮点
どのデータベースを選択するにせよ、将来の拡張に備えた設計を初期段階から取り入れることが重要です。
-
テナント境界の明確化: 全ての主要テーブルに
tenant_idのようなテナントを識別する列を追加します。これは、Citusへの移行やAzure SQLでのシャーディングの際に必須となります。 - ID設計: 単純なシーケンシャルIDは、特定のシャードに書き込みが集中するホットスポットの原因になります。UUIDv7やULIDなど、分散環境でも一意性が保たれ、ソート可能なIDの採用を検討します。
-
接続プーリング: アプリケーションとデータベース間の接続数を効率的に管理するため、
pgBouncer(PostgreSQL) や組み込みの接続プール (SQL Server) の利用は必須です。 - 読み書き分離の抽象化: アプリケーション内で読み取り専用クエリの経路を抽象化しておくと、将来的にリードレプリカへのオフロードが容易になります。
- 非同期処理の活用: 時間のかかる処理や重い書き込みは、キューを介したバックグラウンドジョブに分離し、APIの応答性を保ちます。
サポートとエコシステム
Azure SQL Databaseの安心感
Microsoft自社製品であるため、データベースエンジンからインフラまで一貫した手厚いサポートが受けられます。また、Azure AD、Power BI、Synapse Analyticsなど、他のAzureサービスとの統合もスムーズで、既存のSQL Server資産を持つ企業にとっては最も安心できる選択肢です。
PostgreSQL系のサポート体制
「OSSだからサポートが不安」という声もありますが、Azureが提供するマネージドサービスであるため、インフラ部分（可用性、バックアップ、障害対応など）はMicrosoftが責任を持ってサポートします。エンジン自体のバグについては、MSが一次切り分けを行い、回避策を提示し、最終的な修正はOSSコミュニティに委ねられる形となりますが、「丸投げ」されるわけではありません。
まとめ：どのサービスを選ぶべきか？
最終的にどのサービスを選択すべきか、要件別に整理します。
| サービス | 強み | 弱み | 最適なシナリオ |
|---|---|---|---|
| PostgreSQL Flexible Server | 圧倒的なコスト効率、OSSの柔軟性 | スケールアップのみ、自力での移行計画が必要 | 小〜中規模のSaaS、コストを最優先したいプロジェクトの初期段階 |
| Cosmos DB for PostgreSQL | 透過的な水平スケーラビリティ、PostgreSQL互換 | 分散設計の学習コスト、参照テーブルの制約 | 将来的に大規模なテナント数や高い書き込み性能が予測されるSaaS |
| Azure SQL Database | MSによる手厚いサポート、Azureエコシステムとの親和性 | 高いコスト、水平分割はアプリ側の対応が必要 | エンタープライズシステム、既存のSQL Server資産を活かしたい場合 |
| Azure SQL Database Hyperscale | アプリ透過的な大容量化と読み取りスケール | 非常に高いコスト、書き込み性能には上限あり | TB級の巨大な単一データベースが必要で、読み取り負荷が高いワークロード |
自身のプロジェクトの将来像、予算、チームのスキルセットを総合的に評価し、最適なデータベースを選択することが成功への鍵となります。