Azure SQL Database と Fabric SQL Database：コストとコンピューティングの違いを解説

By Mirko Peters · 2026-10-21

Azure SQL Database と Fabric SQL Database のコンピューティング コスト、サーバーレス スケーリング、キャパシティ ユニット、ストレージの経済性、機能面のトレードオフを比較します。

Automatically translated with AI from the original post. Read the English original

Azure SQL Database と Fabric SQL Database のどちらを選ぶかは、コンピューティングの割り当て、スケーリングの動作、キャパシティ ユニットの違いを理解することに尽きます。どちらも同じ堅牢な SQL エンジン上で動作しますが、Fabric は OneLake との統合や共有キャパシティ モデルを備えているため、データ活用を重視する組織にとっては、アーキテクチャとコストの両面で独自の検討事項が生まれます。

重要なポイント

• Fabric SQL Database は、スタンドアロンの Azure vCore 階層ではなく、共有の Fabric キャパシティ ユニット (CU) を利用します。
• コンピューティング リソースは、15 分間アイドル状態が続くとゼロまでスケールダウンされ、自動的に解放されてコストを抑えます。
• ストレージは 1 時間単位で継続的に課金されます。一方、バックアップ ストレージは、プライマリ データベースのサイズまでは無料です。
• 組み込みの自動ミラーリングにより、手動の ETL パイプラインは不要になり、Delta Parquet ファイルが OneLake にリアルタイムで格納されます。
• 従来の Azure SQL Database では、専用のエラスティック プールや SQL Server Agent ジョブを利用できますが、Fabric 環境ではこれらを別の方法で扱います。

コンピューティングの理解：vCore とキャパシティ ユニットの違い

ワークロードの移行や新しいクラウド アーキテクチャを計画する際、従来の Azure SQL と Fabric SQL の根本的な違いはコンピューティングの管理方法にあります。スタンドアロンの Azure SQL Database では、個々のデータベース インスタンスに直接対応する専用の vCore またはサーバーレス コンピューティングをプロビジョニングします。スケーリングの上限、メンテナンス時間枠、パフォーマンス階層は、データベースごとに管理します。

これに対して、Fabric SQL Database のコンピューティング能力は、組織全体の Fabric キャパシティ プールから供給されます。この共有リソース モデルでは、データベースは Power BI レポート、Data Factory パイプライン、Lakehouse と予算を共有します。Fabric キャパシティ ユニット (CU) とデータベースの処理能力の換算は、内部で動的に処理されます。たとえば、64 キャパシティ ユニットの割り当ては、データベース ワークロードにおおよそ 24.5 vCore に相当します。この統合プール方式により、複数データベース環境で一般的なリソースの分断を防ぎ、分析ワークスペース全体で動的にリソースを共有できます。

サーバーレス スケーリングとアイドル時の課金ルール

どちらのデータベース サービスも、クエリの実行が集中するとスケールアップし、トラフィックが落ち着くとスケールダウンするサーバーレス アーキテクチャを採用しています。ただし、アイドル時間の課金の仕組みは、予算予測にとって特に重要です。Fabric SQL Database はアクティビティを継続的に監視します。データベースに 15 分間まったく受信クエリがない完全なアイドル状態が続くと、すべてのコンピューティング リソースを解放し、コンピューティングのコストはゼロになります。

次のユーザーのコールド スタートによる遅延を防ぐため、Microsoft は意図的な保持バッファーを設けています。データベースが 2 分間集中的に処理された後に静かになった場合、その 2 分間の稼働分に加えて、待機状態のコンピューティングに対する追加の 15 分間、合計 17 分分の課金が発生します。一方、ストレージは変動せず、データベースがトランザクションを処理しているか、スリープしているかにかかわらず、1 時間ごとに課金され続けます。

ストレージのコストとバックアップの経済性

Fabric SQL Databaseのストレージ管理は、従来の構成と比べてコスト面で大きな利点があります。データベースがOneLakeへの継続的なミラーリングを自動的に開始するため、運用データはオープンなDelta Parquetファイルとして複製されます。このオープンな形式によってデータが独自のサイロに閉じ込められることはなく、Delta形式を読み取れるツールであれば、ミラーされたコピーに直接クエリを実行できます。

さらに、Fabricエコシステムではバックアップのコストも大幅に最適化されています。ポイントインタイム リストア機能を使うと、管理者は最大7日前まで時間を巻き戻し、誤操作によるデータ破損や重大なユーザーエラーから復旧できます。バックアップ ストレージは、プライマリ データベースの合計サイズまでは無料です。追加料金が発生するのは、バックアップ ストレージの使用量がアクティブなデータベース自体のサイズを超えた場合のみです。長期的なデータ保持に対して、予測しやすい経済的な安全策となります。

運用上のトレードオフ: 得られるものと失うもの

コア SQL エンジンは両プラットフォームで同一ですが、Azure SQL Databaseの代わりにFabric SQL Databaseを選ぶ場合は、機能面のトレードオフを評価する必要があります。Fabricの実装に何が含まれていないかを把握しておけば、開発中に予期せぬアーキテクチャ上の障害を避けられます。

従来のAzure SQLのみの機能

スタンドアロンのAzure SQL Databaseは、名前によるエラスティック プールをネイティブにサポートしており、データベース管理者はデータベースのグループ化をきめ細かく制御できます。また、従来のSQL Server Agentも含まれています。多くのレガシーアプリケーションは、ストアド プロシージャやメンテナンス タスクのスケジュール実行を内部でこれに依存しています。

Fabric SQLのネイティブな利点

Fabric SQLでは、外部のレプリケーション パイプラインを構築する管理作業が不要になります。データベースを作成した時点で、サポートされるすべてのテーブルに対してミラーリングが自動的に有効になり、手動でのETL構成は必要ありません。さらに、ソース管理のためのGitとネイティブに統合されており、3部構成の名前付け規則をサポートしているため、運用テーブルをLakehouseやWarehouseと1つのクエリで簡単に結合できます。これらの要素がどのように組み合わさるかの全体像については、エピソード全編を聴いて、最新のデータ アーキテクトに向けた専門家の分析と実践的な戦略をご確認ください。

よくある質問

アイドル状態のFabric SQL Databaseの課金はどのように行われますか?

コンピュート課金は、最後のクエリの実行が終了してから15分間継続し、データベースをウォーム状態に保つための時間となります。その後、コンピュート コストはゼロになります。ストレージは、アクティビティの有無にかかわらず毎時課金され続けます。

OneLakeにデータを取り込むために、ミラーリングを手動で構成する必要がありますか?

いいえ。Fabric SQL Databaseの作成と同時にミラーリングが自動的に開始され、カスタムETLコードを使わずに、リレーショナル テーブルをオープンなDelta Parquetファイルとして継続的にOneLakeへ同期します。

Fabric SQL Databaseでジョブのスケジュール実行に SQL Server Agent を使用できますか?

SQL Server AgentはFabric SQL Databaseでは利用できません。代わりに、スケジュール設定と自動化には、Data Factoryパイプライン、またはApache Airflowジョブの利用が推奨されています。

Fabric SQLのバックアップはどのように課金されますか?

ポイントインタイム リストアのバックアップは、アクティブなデータベースの合計ストレージ サイズまでは無料です。バックアップの使用量がプライマリ データベースのサイズを超えた場合にのみ、バックアップ ストレージの料金が発生します。