Las licencias de SQL Server son uno de los puntos que antes o después todo administrador de bases de datos debe dominar. Elegir entre el modelo Servidor + CAL o el de Licencia por Núcleo impacta directamente en el presupuesto, en la escalabilidad futura y, sobre todo, en la tranquilidad frente a una auditoría de Microsoft.
¿Por qué importan las CAL en un servidor dedicado a SQL Server?
Cuando un único servidor físico o virtual está reservado a SQL Server, surge la duda: «Si la máquina solo ejecuta la base de datos, ¿tengo que pagar licencias de acceso para cada PC, usuario o aplicación que se conecte?». La respuesta corta es: depende del modelo de licenciamiento que elijas. A continuación, ampliamos la explicación.
Modelos de licencia de SQL Server y su relación con las CAL
| Modelo de licencia | ¿Se compran CAL? | Cuándo conviene |
|---|---|---|
| Por núcleo (Per Core) | No. La licencia cubre un número concreto de núcleos físicos o vCPU. | Muchos usuarios o dispositivos. Accesos externos o difíciles de contabilizar. Crecimiento imprevisible. |
| Servidor + CAL | Sí. Además de la licencia de servidor, se exige un CAL por usuario o por dispositivo que se conecte (directa o indirectamente). | Pocos usuarios o dispositivos estables. Presupuesto limitado y entorno controlado. |
Tipos de CAL en detalle
- User CAL – La licencia viaja con la persona. Ideal para usuarios que se conectan desde varios dispositivos: PC en la oficina, portátil, móvil, etc.
- Device CAL – La licencia se asocia al dispositivo. Rentable en entornos donde varios turnos comparten un mismo terminal, por ejemplo, un punto de venta.
Límites y excepciones que debes conocer
- SQL Server Express: es gratuito y no requiere CAL, pero impone límites severos (1 GB de RAM, 10 GB por base de datos, un solo núcleo aprovechable por instancia, etc.). Sirve para desarrollo o workloads ligeros, no para producción con alta concurrencia.
- Uso “solo interno”: incluso si el servidor está detrás del firewall y solo lo usan empleados, necesitas CAL si optas por el modelo Servidor + CAL. La única excepción práctica es licenciar todo el motor por núcleos.
- Acceso de terceros: clientes, socios o usuarios anónimos de una web pública se consideran “externos”. Contarlos individualmente es imposible, así que la vía realista es licenciar por núcleo. El coste resulta mayor al principio, pero evita incumplimientos.
- Multiplexores y capas intermedias: si una aplicación, servicio web o API se conecta a SQL Server y a su vez atiende peticiones de usuarios, cada usuario final necesita su CAL, aunque nunca haga una conexión directa. Este punto suele fallar en auditorías.
- Contenedores y microservicios: desde SQL Server 2019, se permiten contenedores Linux. El licenciamiento se mide igualmente por núcleo (el de la VM o nodo) o con Servidor + CAL para entornos de laboratorio.
Cálculo práctico de licencias por núcleo
Microsoft vende los core licenses por pares. Ejemplo: un host dual socket con 2 CPU de 10 núcleos físicos cada una se traduce en 20 núcleos. Debes adquirir 10 paquetes (20 núcleos / 2 núcleos por paquete). Además, el mínimo es cuatro núcleos por VM, incluso si la asignas con 2 vCPU.
Comparativa de costes orientativa
| Escenario | Licencia por Núcleo | Servidor + CAL |
|---|---|---|
| 50 usuarios, 1 servidor de 8 núcleos | Comprar 8 núcleos Coste alto inicial Expandible sin CAL | 1 licencia de servidor + 50 User CAL Más barato si no se añaden usuarios |
| 250 usuarios internos y 500 clientes externos | Comprar núcleos (8, 16, 24… según carga) Evita contar externos | Impracticable: cada cliente necesitaría CAL Coste y gestión inmanejables |
| 20 terminales compartidos, 3 turnos, total 100 empleados | Licenciar 8 núcleos | 1 licencia de servidor + 20 Device CAL Opción más económica |
Importante: los precios cambian anualmente y varían por país y canal (OLP, CSP, SPLA, etc.). Usa este cuadro solo como referencia conceptual.
Licenciamiento en entornos virtualizados y de alta disponibilidad
Virtualización
Si la VM corre en un clúster de hipervisor donde puede migrar libremente (vMotion, Live Migration), tienes dos opciones:
- Licenciar todos los hosts físicos por núcleo: cubre movimiento ilimitado de VM.
- Restringir afinidad: obligas a que la VM se ejecute solo en nodos con licencias activas. Requiere controles técnicos y auditorías internas.
Alta disponibilidad (Always On, Log Shipping, Mirroring)
Con versiones actuales, un nodo secundario pasivo dedicado a la recuperación ante desastres no necesita licencia adicional, siempre que:
- Permanezca en modo pasivo (sin lecturas de usuarios).
- Se active exclusivamente cuando el primario falla y durante un máximo de 30 días al año para pruebas.
Si permites consultas de lectura en el secundario, cuenta como servidor con carga de producción y debe licenciarse igual que el primario.
Entornos de pruebas y desarrollo
El acuerdo Microsoft Developer Network (MSDN) incluye ISO y licencias de SQL Server para no producción. Solo los usuarios con suscripción activa pueden emplearlas en máquinas aisladas de producción. Otra alternativa es usar la edición Developer, gratuita pero exclusiva para desarrollo y test.
Auditorías: cómo pasar el examen sin sustos
- Mantén un inventario actualizado: CPUs, núcleos, versiones, ediciones y modo de licenciamiento de cada instancia.
- Archiva los contratos y facturas en PDF y, si puedes, en un repositorio de control de versiones con cifrado.
- Automatiza la recolección de métricas (registro de conexiones, contadores de rendimiento, uso de CPU real) para justificar dimensionamientos.
- Documenta cambios de arquitectura: nuevos servidores, contenedores, réplica de lectura, etc.
- Realiza una preauditoría interna anual con las herramientas oficiales (Microsoft Assessment and Planning Toolkit, scripts de SQL Server License Evaluator, etc.).
Checklist rápido antes de decidir
- Contabiliza usuarios, dispositivos y crecimiento previsto a 3‑5 años.
- ¿Habrá acceso de clientes externos, API públicas o partners?
- Define si la VM necesitará moverse libremente por un clúster.
- Valora los costes de HA/DR y entornos de ensayo.
- Consulta el presupuesto de CAPEX vs OPEX: pago único on‑prem vs. coste mensual en Azure SQL Database.
- Pide a tu Microsoft Licensing Solution Provider (LSP) una comparativa oficial; los descuentos por volumen pueden invertir los cálculos.
Errores comunes que elevan la factura
- Olvidar que un servicio web que “oculta” SQL sigue necesitando CAL para cada usuario final.
- Asumir que los terminales de un VDI “heredan” la CAL del usuario — no siempre ocurre, revisa tu contrato de virtualización.
- Activar replicación de lectura en un DR secundario y no licenciarlo.
- No considerar la sobreasignación de vCPU: si el host tiene 32 núcleos y varias VM, pagarás los 32 aunque solo uses 12 para SQL.
Buenas prácticas para mantener los costes bajo control
Más allá del modelo de licenciamiento, hay técnicas operativas que reducen el consumo de CPU y, por ende, el número de núcleos licenciados:
- Indexar correctamente y archivar datos históricos.
- Uso ajustado de compresión y particionamiento.
- Activar Query Store para detectar planes subóptimos.
- Ajustar Max DOP y coste de umbral para planes paralelos.
- Consolidar instancias en clústeres o contenedores sin sobrepasar límites de RAM.
Conclusión
Escoger entre Licencia por Núcleo y Servidor + CAL no es un acto de fe: es un cálculo basado en usuarios, dispositivos, picos de carga y políticas de crecimiento. Si tu organización:
- Crece rápido, atiende a clientes externos o no puede contar usuarios con facilidad, licenciar por núcleo evita dolores de cabeza.
- Tiene un número reducido y estable de usuarios internos, Servidor + CAL suele salir más barato a medio plazo.
En todo caso, revisa tu contrato cada vez que añadas CPU, nodos o modelos de negocio. Un ligero cambio arquitectónico puede invalidar la estrategia de licencias y disparar costes o riesgos legales.