Azure SQL Database vs Fabric SQL Database : différences de coût et de calcul expliquées

By Mirko Peters · 2026-10-21

Comparez les coûts de calcul, la mise à l’échelle serverless, les unités de capacité, l’économie du stockage et les compromis fonctionnels d’Azure SQL Database et de Fabric SQL Database.

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

Le choix entre Azure SQL Database et Fabric SQL Database repose sur la compréhension des différences d’allocation du calcul, de comportement de mise à l’échelle et d’unités de capacité. Bien que les deux reposent sur le même moteur SQL robuste, l’intégration de Fabric à OneLake et ses modèles de capacité partagée introduisent des considérations architecturales et financières distinctes pour les organisations orientées données.

Points clés

• Fabric SQL Database puise dans les unités de capacité (CU) partagées de Fabric, et non dans des niveaux vCore Azure autonomes.
• Les ressources de calcul descendent à zéro et sont libérées automatiquement après 15 minutes d’inactivité, afin de réduire les coûts.
• Le stockage est facturé en continu à l’heure, tandis que le stockage de sauvegarde est gratuit jusqu’à la taille de votre base de données principale.
• La mise en miroir automatique intégrée supprime les pipelines ETL manuels en alimentant OneLake en temps réel avec des fichiers Delta Parquet.
• Azure SQL Database traditionnel propose des pools élastiques dédiés et des tâches SQL Server Agent que les environnements Fabric gèrent différemment.

Comprendre le calcul : vCores ou unités de capacité

Lors de la migration de charges de travail ou de la planification d’une nouvelle architecture cloud, la différence fondamentale entre Azure SQL traditionnel et Fabric SQL réside dans la gestion du calcul. Dans une Azure SQL Database autonome, vous provisionnez des vCores dédiés ou un calcul Serverless, directement associés à votre instance de base de données. Vous gérez les limites de mise à l’échelle, les fenêtres de maintenance et les niveaux de performance base de données par base de données.

En revanche, une Fabric SQL Database puise sa puissance de calcul dans le pool de capacité Fabric plus large de votre organisation. Ce modèle de ressources partagées signifie que votre base de données partage un budget avec les rapports Power BI, les pipelines Data Factory et les Lakehouses. La conversion entre les unités de capacité Fabric (CU) et la puissance de la base de données s’effectue dynamiquement en coulisse. Par exemple, une allocation de 64 unités de capacité correspond à peu près à 24,5 vCores pour votre charge de travail de base de données. Cette approche en pool unifié évite la fragmentation des ressources courante dans les environnements multibases et permet un partage dynamique au sein de votre espace de travail analytique.

Mise à l’échelle serverless et règles de facturation en période d’inactivité

Les deux offres de bases de données utilisent des architectures serverless qui montent en charge pendant les pics d’exécution des requêtes et redescendent lorsque le trafic diminue. Toutefois, les mécanismes de facturation en période d’inactivité sont particulièrement importants pour la prévision budgétaire. Une Fabric SQL Database surveille l’activité en continu. Si une base reste totalement inactive pendant 15 minutes sans requête entrante, elle libère toutes ses ressources de calcul, et son coût de calcul tombe à zéro.

Pour éviter la latence de démarrage à froid pour l’utilisateur suivant, Microsoft applique une marge de maintien délibérée. Si une base travaille intensément pendant deux minutes puis devient silencieuse, vous êtes facturé pour ces deux minutes actives, auxquelles s’ajoutent 15 minutes supplémentaires de calcul maintenu en attente, soit un total de 17 minutes. En revanche, le stockage reste constant et est facturé chaque heure, que la base traite activement des transactions ou qu’elle soit en veille.

Coûts de stockage et économie des sauvegardes

La gestion du stockage dans Fabric SQL Database offre des avantages de coût considérables par rapport aux configurations héritées. Comme la base de données lance automatiquement une mise en miroir continue vers OneLake, vos enregistrements opérationnels sont dupliqués dans des fichiers Delta Parquet ouverts. Ce format ouvert garantit que vos données ne sont jamais enfermées dans un silo propriétaire : tout outil capable de lire le format Delta peut interroger directement la copie mise en miroir.

Par ailleurs, l’économie des sauvegardes est fortement optimisée dans l’écosystème Fabric. Les capacités de restauration ponctuelle permettent aux administrateurs de remonter le temps jusqu’à sept jours pour récupérer des données corrompues accidentellement ou des erreurs utilisateur catastrophiques. Le stockage des sauvegardes est entièrement gratuit à hauteur de la taille totale de votre base de données principale. Des frais supplémentaires ne s’appliquent que si l’empreinte de stockage de vos sauvegardes dépasse la taille de la base active elle-même, ce qui constitue un filet de sécurité financier prévisible pour la conservation de données à long terme.

Compromis opérationnels : ce que vous gagnez et ce que vous perdez

Bien que le moteur SQL central soit identique sur les deux plateformes, le choix de Fabric SQL Database plutôt qu’Azure SQL Database impose d’évaluer des compromis fonctionnels précis. Savoir ce qui manque à l’implémentation Fabric permet d’éviter des obstacles architecturaux inattendus pendant le développement.

Fonctionnalités propres à Azure SQL traditionnel

Les bases de données Azure SQL autonomes prennent en charge nativement les pools élastiques, en les désignant par leur nom, ce qui offre aux administrateurs de bases de données un contrôle précis sur les regroupements de bases. Elles incluent également le classique SQL Server Agent, sur lequel de nombreuses applications héritées s’appuient pour planifier en interne les procédures stockées et les tâches de maintenance.

Avantages natifs de Fabric SQL

Fabric SQL supprime la charge administrative liée à la mise en place de pipelines de réplication externes. Dès la création de la base de données, la mise en miroir s’active automatiquement pour toutes les tables prises en charge, sans configuration ETL manuelle. De plus, il s’intègre nativement à Git pour la gestion de code source et prend en charge les conventions de nommage en trois parties, ce qui vous permet de joindre facilement les tables opérationnelles aux Lakehouses et aux Warehouses en une seule requête. Pour une vue d’ensemble complète de la façon dont ces éléments s’articulent, écoutez l’épisode complet pour entendre l’analyse d’experts et les stratégies pratiques destinées aux architectes de données modernes.

Questions fréquentes

Comment fonctionne la facturation d’une Fabric SQL Database inactive ?

La facturation du calcul se poursuit pendant 15 minutes après la fin de votre dernière requête, afin de maintenir la base de données active ; ensuite, les coûts de calcul tombent à zéro. Le stockage continue d’être facturé à l’heure, quelle que soit l’activité.

Dois-je configurer manuellement la mise en miroir pour envoyer les données vers OneLake ?

Non. La mise en miroir démarre automatiquement dès la création de votre Fabric SQL Database et synchronise en continu vos tables relationnelles vers OneLake sous forme de fichiers Delta Parquet ouverts, sans code ETL personnalisé.

Puis-je utiliser SQL Server Agent pour planifier des tâches dans une Fabric SQL Database ?

SQL Server Agent n’est pas disponible dans Fabric SQL Database. Microsoft recommande plutôt d’utiliser des pipelines Data Factory ou des tâches Apache Airflow pour la planification et l’automatisation.

Comment les sauvegardes sont-elles facturées dans Fabric SQL ?

Les sauvegardes de restauration ponctuelle sont entièrement gratuites à hauteur de la taille totale de stockage de votre base de données active. Vous ne payez le stockage des sauvegardes que si leur empreinte dépasse la taille de la base principale.