Azure SQL Database vs. Fabric SQL Database: diferencias de coste y de cómputo explicadas

By Mirko Peters · 2026-10-21

Compara los costes de cómputo, el escalado sin servidor, las unidades de capacidad, la economía del almacenamiento y los compromisos funcionales de Azure SQL Database y Fabric SQL Database.

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

Elegir entre Azure SQL Database y Fabric SQL Database se reduce a entender en qué se diferencian la asignación de cómputo, los comportamientos de escalado y las unidades de capacidad. Aunque ambas se ejecutan sobre el mismo motor SQL robusto, la integración de Fabric con OneLake y sus modelos de capacidad compartida introducen consideraciones arquitectónicas y de coste distintas para las organizaciones basadas en datos.

Puntos clave

• Fabric SQL Database utiliza las unidades de capacidad (CU) compartidas de Fabric, en lugar de los niveles de vCore independientes de Azure.
• Los recursos de cómputo escalan a cero y se liberan automáticamente tras 15 minutos de inactividad para ahorrar costes.
• El almacenamiento se factura continuamente por horas, mientras que la copia de seguridad es gratuita hasta el tamaño de tu base de datos principal.
• La duplicación automática integrada elimina los canales ETL manuales al llenar archivos Delta Parquet en OneLake en tiempo real.
• Azure SQL Database tradicional ofrece grupos elásticos dedicados y trabajos de SQL Server Agent que los entornos de Fabric gestionan de otra manera.

Entender el cómputo: vCores frente a unidades de capacidad

Al migrar cargas de trabajo o planificar una nueva arquitectura en la nube, el cambio fundamental entre el Azure SQL tradicional y Fabric SQL está en la gestión del cómputo. En una Azure SQL Database independiente, aprovisionas vCores dedicados o cómputo sin servidor que se asigna directamente a tu instancia de base de datos. Gestionas los límites de escalado, las ventanas de mantenimiento y los niveles de rendimiento base de datos por base de datos.

En cambio, una Fabric SQL Database toma su potencia de cálculo del conjunto de capacidad de Fabric de tu organización. Este modelo de recursos compartidos significa que tu base de datos comparte presupuesto con los informes de Power BI, las canalizaciones de Data Factory y los Lakehouses. La conversión entre las unidades de capacidad de Fabric (CU) y la potencia de la base de datos se gestiona de forma dinámica por debajo. Por ejemplo, una asignación de 64 unidades de capacidad equivale aproximadamente a 24,5 vCores para la carga de trabajo de tu base de datos. Este enfoque de conjunto unificado evita la fragmentación de recursos habitual en entornos con varias bases de datos y permite compartir recursos de forma dinámica en tu área de trabajo analítica.

Escalado sin servidor y reglas de facturación en inactividad

Ambas opciones de base de datos utilizan arquitecturas sin servidor que escalan al alza durante los picos de ejecución de consultas y vuelven a bajar cuando disminuye la actividad. Sin embargo, mecánica de facturación del tiempo inactivo es especialmente importante para la previsión presupuestaria. Una Fabric SQL Database supervisa la actividad de forma continua. Si una base de datos permanece completamente inactiva durante 15 minutos sin consultas entrantes, libera todos sus recursos de cómputo y el coste de cómputo baja a cero.

Para evitar la latencia de arranque en frío para el siguiente usuario, Microsoft aplica un margen de retención deliberado. Si una base de datos trabaja intensamente durante dos minutos y luego se queda inactiva, se te facturarán esos dos minutos activos más 15 minutos adicionales de cómputo en espera, es decir, un total de 17 minutos. El almacenamiento, en cambio, permanece constante y se factura cada hora, tanto si la base de datos procesa transacciones como si está en reposo.

Costes de almacenamiento y economía de las copias de seguridad

La gestión del almacenamiento en Fabric SQL Database ofrece ventajas de ahorro de costes importantes frente a las configuraciones tradicionales. Como la base de datos inicia automáticamente una replicación continua en OneLake, tus registros operativos se duplican en archivos Delta Parquet abiertos. Este formato abierto garantiza que tus datos nunca queden atrapados en un silo propietario, ya que cualquier herramienta capaz de leer el formato Delta puede consultar la copia replicada directamente.

Además, la economía de las copias de seguridad está muy optimizada en el ecosistema de Fabric. Las capacidades de restauración a un momento dado permiten a los administradores retroceder en el tiempo hasta siete días para recuperarse de la corrupción accidental de datos o de errores graves de los usuarios. El almacenamiento de copias de seguridad es totalmente gratuito hasta el tamaño total de tu base de datos principal. Solo incurres en cargos adicionales si la huella de almacenamiento de tus copias de seguridad supera el tamaño de la base de datos activa, lo que ofrece una red de seguridad financiera predecible para la retención de datos a largo plazo.

Compensaciones operativas: lo que ganas y lo que pierdes

Aunque el motor SQL principal es idéntico en ambas plataformas, elegir Fabric SQL Database en lugar de Azure SQL Database requiere evaluar compensaciones de funcionalidades específicas. Conocer lo que falta en la implementación de Fabric evita bloqueos arquitectónicos inesperados durante el desarrollo.

Funcionalidades exclusivas de Azure SQL tradicional

Las bases de datos independientes de Azure SQL admiten de forma nativa los grupos elásticos por nombre, lo que ofrece a los administradores de bases de datos un control granular sobre las agrupaciones de bases de datos. También incluyen el clásico SQL Server Agent, en el que confían muchas aplicaciones heredadas para programar procedimientos almacenados y tareas de mantenimiento de forma interna.

Ventajas nativas de Fabric SQL

Fabric SQL elimina la carga administrativa de configurar canalizaciones de replicación externas. En cuanto creas la base de datos, la replicación se activa automáticamente para todas las tablas compatibles, sin necesidad de configuración manual de ETL. Además, se integra de forma nativa con Git para el control de código fuente y admite convenciones de nomenclatura de tres partes, lo que te permite unir fácilmente tablas operativas con Lakehouses y Warehouses en una sola consulta. Para una visión completa de cómo encajan estas piezas, escucha el episodio completo y descubre el análisis de expertos y las estrategias prácticas para arquitectos de datos modernos.

Preguntas frecuentes

¿Cómo funciona la facturación de una base de datos inactiva de Fabric SQL Database?

La facturación de proceso continúa durante 15 minutos después de que termine la última consulta, para mantener la base de datos activa; transcurrido ese tiempo, los costes de proceso pasan a cero. El almacenamiento sigue facturándose por horas independientemente de la actividad.

¿Necesito configurar manualmente la replicación para llevar los datos a OneLake?

No. La replicación se inicia automáticamente en el momento en que se crea tu Fabric SQL Database, sincronizando de forma continua tus tablas relacionales en OneLake como archivos Delta Parquet abiertos, sin necesidad de código ETL personalizado.

¿Puedo usar SQL Server Agent para programar trabajos en una Fabric SQL Database?

SQL Server Agent no está disponible en Fabric SQL Database. En su lugar, Microsoft recomienda usar canalizaciones de Data Factory o trabajos de Apache Airflow para la programación y la automatización.

¿Cómo se facturan las copias de seguridad en Fabric SQL?

Las copias de seguridad de restauración a un momento dado son totalmente gratuitas hasta el tamaño total de almacenamiento de tu base de datos activa. Solo pagas el almacenamiento de copias de seguridad si su huella supera el tamaño de la base de datos principal.