Una VM con SQL Server puede facturar aunque la base de datos apenas trabaje; Azure SQL Database, en cambio, ofrece cómputo serverless que se cobra por segundo y puede pausarse. Esa diferencia resume el dilema de costes, pero no basta para escoger: también cuentan la licencia, los discos, las copias, la alta disponibilidad y el trabajo operativo que asume el equipo.
Para comparar ambas opciones en 2026 hay que partir de una carga concreta. Microsoft advierte que sus precios varían según la región y el acuerdo, y su página de Azure SQL Database presenta estimaciones, no cotizaciones finales. Por eso, la comparación útil no es una tarifa universal, sino el desglose de lo que cada arquitectura pone en la factura.
Qué entra en la factura de cada opción
Azure SQL Database es un servicio gestionado: Microsoft administra el sistema operativo, el motor de SQL Server, las actualizaciones, las copias de seguridad y la alta disponibilidad integrada. El cliente paga principalmente por cómputo y almacenamiento; según la configuración, también puede haber cargos por almacenamiento de copias, retención prolongada o redundancia adicional.
El cómputo se puede contratar con DTU, que agrupan CPU, memoria y entrada/salida, o con vCore, que permite ajustar esos recursos por separado. En vCore hay cómputo aprovisionado —una capacidad fija facturada por hora— y serverless, destinado a bases con uso intermitente o imprevisible. Este último escala el cómputo automáticamente y factura por segundo mientras se utiliza.
En serverless, la pausa automática reduce el coste de cómputo a cero durante la pausa: queda el almacenamiento. Pero una conexión abierta puede impedir que la base se duerma. El artículo de SQL & Cloud Lab señala como posibles causas una sesión de SSMS, los pools de conexiones de la aplicación y las comprobaciones de salud. Si alguna mantiene la base activa, el ahorro esperado puede no materializarse.
La VM factura por la máquina mientras está en ejecución, esté SQL Server ocupado o no. A ese importe se suman la licencia de SQL Server —salvo que se aporte una licencia válida o se use una edición sin coste—, los discos del sistema operativo, datos y registros, las copias y, si se busca alta disponibilidad con un grupo Always On, al menos otra VM y sus discos.
También hay un coste operativo menos visible: en la VM, el equipo se ocupa de parches, monitorización, pruebas de restauración y planificación de la conmutación por error. Azure SQL Database desplaza esas tareas de plataforma a Microsoft. La diferencia no aparece necesariamente como una línea única en la factura, pero sí cambia qué recursos internos exige cada alternativa.
Comparación de costes y capacidades
| Criterio | Azure SQL Database | SQL Server en Azure VM |
|---|---|---|
| Cómputo | DTU o vCore. Serverless cobra por segundo de uso; el aprovisionado factura una capacidad fija por hora. | La VM factura por hora mientras está encendida, incluso si la carga de SQL es baja. |
| Coste en inactividad | En serverless puede reducirse al almacenamiento si la base se pausa; las conexiones abiertas pueden evitarlo. | La VM sigue generando cargos hasta que se apaga y desasigna. |
| Licencia de SQL Server | Incluida en el servicio o con descuento mediante Azure Hybrid Benefit en vCore aprovisionado. | Incluida en algunas imágenes de pago por uso o cubierta mediante Azure Hybrid Benefit si se cumplen los requisitos. |
| Almacenamiento | Se cobra según el nivel y el almacenamiento provisionado o asignado; el coste depende de la configuración. | Se pagan los discos de sistema operativo, datos y registros. Los discos Premium SSD o Ultra pueden elevar el total. |
| Copias de seguridad | Copias automáticas con una cantidad de almacenamiento incluida; retención adicional y consumo extra pueden generar cargos. | El cliente configura y paga Azure Backup o el almacenamiento de copias en Blob. |
| Alta disponibilidad | Alta disponibilidad integrada; algunas opciones, como la redundancia de zona en General Purpose, añaden coste. | Puede requerir una segunda VM, discos y licencias, según el diseño y los derechos de licencia aplicables. |
| Administración | Microsoft gestiona el sistema operativo, los parches, las copias y la alta disponibilidad del servicio. | El equipo administra el sistema operativo y tareas como parches, monitorización y pruebas de recuperación. |
| Control de instancia | Menos funciones de instancia; el artículo comparativo cita como límites SQL Agent y las consultas entre bases. | Control de una instancia completa, con acceso al sistema operativo y posibilidad de instalar software junto a SQL Server. |
| Licencias existentes | Azure Hybrid Benefit solo está disponible en el modelo vCore con cómputo aprovisionado; no se aplica a DTU ni serverless. | Azure Hybrid Benefit reduce el coste de licencia, pero no elimina el coste base de cómputo, almacenamiento, copias ni E/S. |
La tabla muestra por qué no conviene comparar solo el precio del cómputo. Una VM pequeña puede parecer barata, pero esa cifra no incluye necesariamente la licencia de SQL Server: Microsoft Learn aclara que la estimación que aparece al elegir el tamaño de una VM incluye el cómputo y, cuando corresponda, la licencia del sistema operativo, pero no la licencia de SQL Server Web, Standard o Enterprise. Para afinar el cálculo hay que seleccionar también la edición de SQL Server.
Licencias y descuentos: el cálculo puede cambiar
Azure Hybrid Benefit puede reducir la parte de licencia en las dos opciones, pero sus condiciones y efecto no son iguales. En Azure SQL Database solo se aplica a vCore aprovisionado. Quedan fuera tanto el modelo DTU como serverless, una distinción importante si la idea es escoger serverless precisamente para recortar el gasto de bases con actividad irregular.
Microsoft indica que el beneficio para Azure SQL Database puede ofrecer ahorros de un 30 % o más al asignar licencias de SQL Server con Software Assurance. Es una referencia de ahorro potencial, no un precio garantizado para cualquier configuración. El importe depende de la licencia disponible y de los recursos que se contraten.
En una VM, Azure Hybrid Benefit también requiere licencias de SQL Server Standard o Enterprise y Software Assurance. Reduce el coste de asignación de licencias, pero la VM, el almacenamiento y las copias siguen facturándose. Microsoft recomienda esta vía para cargas continuas con duración y escala conocidas; para trabajos temporales o de duración incierta, describe el pago por uso de la licencia como una alternativa adecuada.
Hay además ediciones gratuitas para casos delimitados. Developer no tiene coste de licencia y sirve para desarrollo, pruebas o pruebas de concepto, pero no puede usarse en producción. Express tampoco cobra licencia y puede servir para cargas ligeras de producción: Microsoft fija como referencia hasta 4 núcleos, menos de 1 GB de memoria y hasta 50 GB por base de datos. Advierte, sin embargo, que Express carece de algunas funciones necesarias en producción, como opciones de recuperación ante desastres de nivel Enterprise.
Para cargas previsibles, SQL Database ofrece planes de ahorro por comprometer un gasto horario durante uno o tres años y reservas de uno o tres años, según la página de precios de Microsoft. La compra debe encajar con el patrón real de consumo: un compromiso puede rebajar el coste frente al pago por uso, pero no sustituye la medición ni la elección correcta de capacidad. En las VMs, el material de Microsoft destaca el dimensionamiento y el apagado de cargas intermitentes, no una comparación de importes finales entre reservas.
Cuándo elegir Azure SQL Database
Encaja mejor cuando se crea una aplicación nueva, se utiliza una base de datos individual o la carga sube y baja, y el equipo prefiere no administrar parches, copias y alta disponibilidad. Si el uso es irregular, serverless puede ser una buena candidata: el cómputo se cobra por segundo y la base puede pausarse. Para muchas bases pequeñas con actividad desigual, SQL & Cloud Lab recomienda considerar un elastic pool.
La condición es que la aplicación no dependa de funciones de instancia que el servicio no ofrece. El comparativo cita SQL Agent y consultas entre bases como límites de Azure SQL Database; si esas capacidades son necesarias, propone valorar SQL Managed Instance o una VM. La elección del servicio gestionado, por tanto, no es solo una decisión de factura: también depende de cuánto del SQL Server existente puede trasladarse sin cambiar sus requisitos.
Azure SQL Database también resulta más sencillo de presupuestar cuando se quiere delegar la administración del motor y su plataforma, aunque no todos los costes desaparecen: el almacenamiento, la retención larga de copias y determinadas opciones de redundancia todavía pueden mover el total. En serverless hay que comprobar, además, que la base realmente se pause.
Cuándo elegir SQL Server en una VM
La VM es la opción a considerar cuando se necesita control completo de la instancia, acceso al sistema operativo, una versión concreta de SQL Server o software de terceros instalado junto al motor. También encaja con aplicaciones que requieren SQL Agent, SSIS o SSRS en el mismo servidor, según el comparativo de SQL & Cloud Lab.
Ese control tiene un precio operativo y de infraestructura: además de elegir el tamaño de VM y la edición, hay que planificar discos, copias y disponibilidad. Si se apaga la VM, hay que hacerlo correctamente: Microsoft señala que detenerla desde el sistema operativo no basta para evitar cargos; es necesario apagarla y desasignarla. Para cargas que no trabajan todo el tiempo, también recomienda dimensionar la VM según las necesidades reales y considerar apagados durante los periodos inactivos.
Una carga de producción continua con licencias Standard o Enterprise y Software Assurance puede aprovechar Azure Hybrid Benefit en la VM. Microsoft también señala que una licencia asignada puede cubrir una réplica secundaria pasiva para alta disponibilidad y otra para recuperación ante desastres, con las condiciones descritas en su guía. Esto puede recortar el componente de licencia de una arquitectura redundante, aunque no elimina el coste de la infraestructura adicional.
Cómo construir una comparación válida
Antes de migrar, SQL & Cloud Lab recomienda recoger al menos dos semanas de uso real del servidor actual: CPU media y máxima, memoria, IOPS y caudal de escritura del registro. Dimensionar Azure a partir del hardware antiguo, en vez de su utilización efectiva, puede llevar a pagar por capacidad ociosa. Tras el despliegue, propone empezar con un tamaño menor y monitorizar durante una semana antes de escalar si las métricas lo justifican.
Con esos datos, conviene calcular escenarios equivalentes en la calculadora de precios de Azure: mismo volumen de trabajo, nivel de disponibilidad y política de copias. En Azure SQL Database hay que decidir entre DTU o vCore y, en este último, entre serverless y aprovisionado; en la VM, incluir edición de SQL Server, tamaño de máquina y discos. Después se añaden retención, redundancia y licencias, y se considera quién realizará el mantenimiento.
No hay una cifra única para «Azure SQL frente a VM» sin esos parámetros. Como orientación, el servicio gestionado suele tener ventaja para aplicaciones nuevas o variables cuando la pausa serverless funciona y no hacen falta funciones de instancia. La VM puede justificarse por compatibilidad y control, especialmente si la licencia existente y un dimensionamiento ajustado compensan sus componentes adicionales. El siguiente paso es cotizar ambas configuraciones con la región, el acuerdo y las métricas de la carga que realmente se va a migrar.
Fuentes: DEV Community, Microsoft Azure, Microsoft Learn, Microsoft Learn
