SQL Server

23
Ene
2026

BBDD relacionales gratis: opciones en 2026

Durante años, “base de datos relacional gratis” se traducía en una de dos cosas: MySQL por inercia o SQLite por necesidad. Y, si estabas en Windows, SQL Server Express era ese invitado que venía a la fiesta… pero se quedaba sin bebida a los 10 GB. Pues bien: Microsoft ha decidido que ya está bien de hacer el ridículo en este segmento.

SQL Server 2025 Express sube el límite máximo por base de datos a 50 GB y, de paso, elimina el baile de “Express con Advanced Services” porque ahora lo integra en la edición Express. Es un movimiento simple, directo y con mala leche competitiva: “si lo gratis te sirve para una PYME, quizá luego ya pagas”. Y no es mala estrategia.

Antes de meternos en harina, dejemos claro el marco mental: aquí no estamos eligiendo la “mejor” BBDD en abstracto. Estamos eligiendo una herramienta gratis que no te obligue a pagar con sangre en producción: mantenimiento, soporte, migraciones, rendimiento y, sobre todo, expectativas realistas.

Este giro de Microsoft da para abrir el melón: ¿puede SQL Server Express competir de verdad en el terreno de las BBDD relacionales gratuitas, o llega tarde y con limitaciones que lo condenan a “edición de prueba eterna”?

SQL Server Express 2025: La BD gratis perfecta para entornos Windows

SQL Server Express 2025 ya no muere de éxito al crecer un poco. El salto de 10 GB a 50 GB por base de datos cambia el tipo de proyectos donde encaja: aplicaciones de gestión, contabilidad, CRM de PYME, ERPs modestos, integraciones internas… ese mundo on-prem que sigue existiendo aunque a algunos les duela admitirlo.

Ahora bien, lo que Microsoft te da con una mano, te lo recuerda con la otra: Express sigue limitado en cómputo y memoria. La documentación oficial habla de “1 socket o 4 cores” y un buffer pool máximo de 1.410 MB. Es decir, 50 GB sí, pero no esperes que un informe criminal de fin de mes vuele si te dedicas a escanear tablas como si fueran cromos.

En entornos Windows empresariales, SQL Server Express juega con ventaja: instalador, tooling, drivers, autenticación integrada, ecosistema. Y aquí es donde muchos DBAs lo hemos visto triunfar sin aspavientos: un servidor Windows en una PYME, una app “de las de toda la vida” y un proveedor que no quiere complicarse la vida con stack Linux. Sí, puedes dejarlo todo en db_owner y también puedes freír huevos en la placa base. Ambas son malas ideas.

Si quieres verificar rápido qué tienes instalado y en qué edición estás, con esto basta:

SELECT
  SERVERPROPERTY('Edition')     AS Edition,
  SERVERPROPERTY('ProductVersion') AS ProductVersion,
  SERVERPROPERTY('ProductLevel')   AS ProductLevel;

Y si te preocupa el techo de memoria del motor (porque deberías), la tabla de límites por edición es bastante clara: Express vive en el barrio del 1,4 GB de buffer pool.

¿Puede Express pelear en web o la liga gratis ya se juega sin Microsoft?

La web “barata” lleva décadas en LAMP y derivados, así que aquí SQL Server siempre ha tenido que remar a contracorriente. Aun así, con 50 GB ya no se cae a la mínima, y el cambio de “Express Advanced Services desaparece porque ahora viene integrado” también reduce fricción. Menos ediciones raras, menos decisiones estúpidas por desconocimiento.

El problema real no es técnico, es cultural y de ecosistema. Donde ya hay PHP, hosting compartido, paneles de control y proveedores que viven de desplegar WordPress como churros, SQL Server no es el camino por defecto. Y esto importa más de lo que nos gustaría a los que vivimos en T-SQL.

Dicho esto, en la web corporativa interna, en intranets, en integraciones con Active Directory, en aplicaciones .NET de gestión… ahí Express sí puede competir con mucha dignidad. La pregunta no es “¿es el mejor motor?”, sino “¿cuánto te cuesta operarlo con tu equipo y tu contexto?”. En PYMES, eso pesa toneladas.

SQLite: cuando quieres una BD gratis … pero no un servidor

SQLite es el recordatorio incómodo de que muchas veces no necesitas un motor cliente-servidor, sino un fichero fiable y transaccional. SQLite es una librería embebida, serverless, autocontenida y con cero configuración real. Lo metes en tu aplicación, y a correr.

Eso sí, SQLite no es magia. Su modelo de concurrencia tiene límites muy concretos. Para escribir, necesitas un bloqueo exclusivo; solo puede haber un escritor a la vez, y la forma en la que gestiones transacciones y tiempos de bloqueo decide si tu app vive o se llena de SQLITE_BUSY.

Con WAL (Write-Ahead Logging) mejoras la convivencia entre lecturas y escrituras, los lectores no bloquean al escritor y viceversa, pero sigues sin tener “concurrencia de escritores” a lo loco. Es decir, para escenarios sin mucha concurrencia de escritura, o donde el patrón es “muchas lecturas, pocas escrituras”, SQLite es brillante. Para una API con ráfagas de escrituras simultáneas, es una invitación a sufrir.

SQLite encaja de maravilla en escritorio, móvil, IoT, cachés persistentes, herramientas internas, prototipos serios y servicios pequeños donde te interesa simplicidad por encima de todo. Y sí, lo de “es solo para juguete” lo suele decir alguien que no ha leído la documentación desde 2009.

PostgreSQL: la alternativa gratis que gana terreno porque no vive del pasado

Si me preguntas qué motor open source está ganando terreno con más consistencia, PostgreSQL aparece en la conversación antes de que termines la frase. No porque sea “moderno”, sino porque lleva años haciendo bien lo básico y lo difícil: transacciones, concurrencia, extensibilidad, tipos avanzados, rendimiento y una comunidad que no depende de que a una corporación le apetezca publicar commits este trimestre.

En datos de uso por desarrolladores, PostgreSQL aparece como el entorno de base de datos más utilizado en la encuesta de Stack Overflow 2025 (55,6%), por delante de MySQL (40,5%). No es “cuota de mercado” pura, pero sí es una señal fuerte de hacia dónde mira quien construye software hoy.

En el mundo real, PostgreSQL brilla cuando quieres portabilidad, cuando no quieres casarte con un proveedor concreto, cuando tu modelo de datos crece en complejidad o cuando necesitas features potentes sin pagar licencia. Y también cuando quieres dormir tranquilo sabiendo que el proyecto no está “mantenido por accidente”.

¿La pega? Migrar desde MySQL no siempre es trivial. Dialectos, funciones, colaciones, tipos, procedimientos, y esa colección de “pequeñas diferencias” que se convierten en semanas si nadie las planifica. Aun así, cada vez más equipos consideran que el esfuerzo compensa.

MySQL: el rey por herencia… y eso no es un cumplido

MySQL sigue siendo enorme. En popularidad tipo DB-Engines aparece en lo más alto del ranking relacional (segunda tras Oracle en enero de 2026). Y si miras muestras de tecnología en sitios web, Datanyze lo coloca como #1 en su categoría “Databases” con un 21,32% en su dataset.

Ahora viene la parte que muchos prefieren ignorar, herencia no es lo mismo que futuro. MySQL ha sido “la base de datos por defecto” de gran parte del hosting web durante años, y WordPress ha tenido muchísimo que ver en ese dominio. Pero la propia comunidad de WordPress muestra un dato muy revelador: según estadísticas resumidas en junio de 2025, MariaDB ya superaba a MySQL en sitios WordPress (52,8% vs 47,2%). Ese cambio no es teórico, el reinado de MySQL ya pasó.

Y luego está el elefante en la habitación, la actividad pública del repositorio. A fecha 13 de enero de 2026, DevClass reporta que el repositorio GitHub de MySQL Server no recibía commits desde septiembre de 2025, alimentando la percepción de abandono por parte de Oracle o, como mínimo, de desarrollo “a puerta cerrada” priorizando productos comerciales alrededor. Esto no prueba que MySQL “esté muerto”, pero sí afecta a confianza, contribuciones y comunidad.

MySQL puede seguir siendo dominante un tiempo largo, porque cambiar motores en empresas cuesta y da miedo. Pero cuando lo que te mantiene arriba es la inercia, cualquier giro del mercado te hace daño.

MariaDB: el reemplazo natural… hasta que deja de ser “drop-in”

MariaDB nació como fork de MySQL y lleva años intentando ser, de forma explícita, el sucesor natural para quien quiere compatibilidad sin depender de Oracle. La propia MariaDB Foundation insiste en esa narrativa de “successor” y en que la mayoría de usuarios no encuentran problemas de compatibilidad en su día a día.

En la práctica, MariaDB ha ganado muchísimo terreno en hosting y en stacks clásicos web. Y el dato de WordPress que comentaba antes no es casualidad, si un proveedor puede cambiar de MySQL a MariaDB sin que sus clientes se enteren, lo hará. Porque es fácil, porque suele ir bien, y porque reduce riesgo de dependencia.

El matiz importante es el de siempre, “compatible” no significa “idéntico”. A medida que los proyectos divergen, aparecen diferencias en optimizador, funciones, comportamiento, versiones y soporte. Para WordPress y aplicaciones típicas LAMP, suele funcionar como reemplazo. Para software que exprime particularidades del dialecto o dependencias muy concretas, hay que probar muy bien.

Si el mercado web se disputa hoy entre MariaDB y PostgreSQL, MariaDB juega con la ventaja de la continuidad, cambiar menos para obtener algo más.

Entonces… ¿Qué BD gratis elijo si no quiero arrepentirme en seis meses?

La selección sensata empieza por aceptar que “gratis” no significa “sin coste”. El coste es operativo: personas, conocimiento, tooling, automatización, copias, recuperación, monitorización y capacidad de escalar sin convertir cada incidencia en una novela.

Si estás en una PYME Windows, con aplicaciones de gestión y un entorno donde SQL Server encaja como un guante, Express 2025 es más serio que nunca, 50 GB te cubren un montón de escenarios reales, y la integración nativa reduce fricción. No te da alta disponibilidad, pero muchas de esas empresas tampoco la tienen con MySQL, solo que lo llaman de otra forma.

Si necesitas una base embebida, local, simple y robusta, SQLite es casi imbatible. Pero si tienes concurrencia de escritura o varias instancias pegándole fuerte, no fuerces el diseño: no es un clúster, por mucho que te empeñes.

Si quieres un motor open source con tracción clara, comunidad fuerte y cada vez más adopción por desarrolladores, PostgreSQL es la apuesta que más se repite hoy.

Si vienes de MySQL por herencia web, mi consejo profesional es simple, considera seriamente MariaDB como “continuidad sin drama”, y mira PostgreSQL como “salto con futuro”. Y si decides quedarte en MySQL, que sea por motivos técnicos y de negocio, no por costumbre ni por miedo al cambio. Lo de los commits públicos no te rompe mañana, pero sí te debería incomodar.

Conclusión

SQL Server Express 2025 por fin juega en serio en el segmento “gratis”, 50 GB cambian el tipo de proyectos donde encaja, sobre todo en on-prem y entornos Windows de PYME. SQLite sigue siendo el rey cuando no quieres un servidor y tu concurrencia de escritura no es agresiva. PostgreSQL es el que más terreno gana porque la comunidad empuja y el mercado le da la razón. MySQL aguanta por herencia, especialmente web, pero la señal de actividad pública y el desplazamiento hacia MariaDB en WordPress son avisos que un profesional no debería ignorar.

Elegir bien aquí no va de religión: va de minimizar deuda técnica. Y la deuda técnica, como siempre, se paga con intereses.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Otros, 0 comentarios
14
Ene
2026
Most Active Speaker 2025 en Sessionize: gracias por estar ahí

Most Active Speaker 2025 en Sessionize: gracias por estar ahí

Hay reconocimientos que no sirven para adornar el currículum, pero sí para hacer una pausa y revisar el camino recorrido. Este es uno de ellos. Sessionize me ha incluido dentro del top 3 % de speakers más activos, bajo la etiqueta de Most Active Speaker. No es una medalla épica ni una validación divina de mi criterio técnico, pero sí una señal clara de algo muy concreto: he estado presente, de forma constante, compartiendo conocimiento con la comunidad.

Y eso, en este sector, no es tan habitual como nos gusta pensar.

Antes de que nadie saque conclusiones equivocadas, conviene aclarar algo desde el principio: este reconocimiento no va de ego, ni de protagonismo, ni de competir con nadie. Va de constancia, de compromiso y de comunidad. Y por eso este artículo no es para hablar de mí, sino para dar las gracias a quienes estáis al otro lado.

Qué mide realmente Sessionize cuando habla de “Most Active Speaker”

Antes de entrar en agradecimientos, pongamos un poco de contexto técnico, que para eso estamos aquí. Sessionize no reparte este reconocimiento por likes, retuits ni frases inspiradoras. Lo que mide es actividad real: sesiones enviadas, sesiones aceptadas, charlas impartidas, eventos en los que participas, continuidad en el tiempo. Datos. Fríos. Objetivos. Bastante poco románticos, en realidad.

Ser Most Active Speaker no significa ser el mejor ponente ni el más brillante. Significa algo mucho más terrenal: que no has desaparecido después de dos eventos, que no llevas cinco años reciclando la misma presentación y que sigues teniendo algo que aportar. Significa que has invertido horas, muchas de ellas fuera del horario laboral, preparando contenido, actualizándolo y adaptándolo a audiencias distintas.

Sí, también significa fines de semana, viajes incómodos y alguna que otra demo que decide romperse justo cuando no debería. Forma parte del pack.

La constancia como valor técnico (aunque no venda tanto)

En tecnología nos encanta hablar de innovación, pero sobrevivimos gracias a la constancia. Lo mismo pasa con las charlas. Dar una buena sesión una vez es relativamente fácil. Mantener un nivel digno durante años, revisando contenido y aceptando que lo que explicabas hace dos versiones ya no aplica, es otra historia.

Este reconocimiento, si tiene algún valor, es precisamente ese: refleja continuidad. Estar ahí cuando hay que estar. Seguir enviando sesiones aunque no todas entren. Aceptar charlas pequeñas con el mismo respeto que las grandes. Y entender que el aprendizaje no va en línea recta, sino a base de iteraciones, errores y correcciones.

Exactamente igual que trabajamos en producción, por cierto.

Esto no se hace solo (y quien lo crea, se engaña)

El mito del speaker autosuficiente es eso, un mito. Nadie da charlas en el vacío. Detrás de cada sesión hay organizadores que confían en ti, comunidades que te abren la puerta y asistentes que deciden invertir su tiempo en escucharte en lugar de irse a por café. Y eso no es poca cosa.

Las mejores sesiones no empiezan ni acaban en las slides. Empiezan cuando alguien te plantea un problema real y terminan cuando la conversación continúa fuera del escenario. Ahí es donde salen los “depende”, los matices y las decisiones incómodas que no caben en una demo limpia. Y ahí es donde se aprende de verdad.

Este reconocimiento existe porque existe esa interacción constante con profesionales reales: DBAs, desarrolladores, arquitectos y gente de sistemas que ha vivido situaciones que no aparecen en la documentación oficial. Nuestra gente.

Gracias a quienes leéis, preguntáis y cuestionáis

Si sigo dando charlas y escribiendo artículos técnicos es, en gran medida, por el feedback que recibo de quienes seguís el blog y participáis en las sesiones. Muchas charlas nacen de preguntas recurrentes, de errores que veo repetirse una y otra vez o de malas prácticas que siguen vivas contra todo pronóstico.

Ese intercambio es lo que evita que el contenido se convierta en una colección de slides bonitas pero inútiles. Cuando alguien te escribe para decirte que ha aplicado algo que explicaste y le ha ahorrado un problema serio, eso vale más que cualquier badge.

Y también cuando alguien discrepa con argumentos. Porque en este sector, quien te rebate bien te está regalando tiempo y atención. Lo contrario, el asentimiento acrítico, no aporta nada.

La comunidad no es un eslogan

Se habla mucho de comunidad, pero pocas veces se define. Para mí no es un hashtag ni una foto de grupo al final de un evento. Es una red informal de profesionales que comparten conocimiento sin postureo, que se ayudan sin esperar retorno inmediato y que entienden que aprender en solitario es posible, pero agotador.

La comunidad es lo que hace que tenga sentido escribir artículos largos, técnicos y sin concesiones. Lo que permite que un reconocimiento como este exista. Y lo que mantiene viva la motivación cuando el cansancio aprieta.

No todo es ideal, por supuesto. Hay charlas con poco público, eventos que no salen como esperabas y sesiones que no terminan de encajar. Pero incluso eso forma parte del aprendizaje. Nadie prometió glamour, y quien lo busque probablemente se ha equivocado de profesión.

Decir que no también forma parte de ser activo

Ser activo no es aceptar todo lo que llega. De hecho, con los años he aprendido justo lo contrario. La constancia se mantiene eligiendo bien dónde aportar valor. No todos los eventos encajan, no todas las charlas merecen el mismo esfuerzo y no todas las propuestas ayudan a crecer.

Revisar contenidos, actualizar ejemplos y aceptar que lo que funcionaba hace un año hoy necesita cambios es parte del trabajo. Las slides envejecen. El código también. Y pensar lo contrario suele acabar mal, normalmente delante de una audiencia que sí se ha mantenido al día.

Sessionize como reflejo del ecosistema

Sessionize se ha convertido, nos guste más o menos, en un punto central para speakers y organizadores. No es perfecta, pero cumple su función. Y que un reconocimiento así se base en datos y no en percepciones lo hace más honesto.

No es una votación popular ni un premio subjetivo. Es un reflejo de actividad real. Y eso, para perfiles técnicos, suele ser más cómodo que cualquier discurso grandilocuente lleno de adjetivos vacíos.

Por eso valoro este reconocimiento. No por el “top 3 %”, sino porque detrás hay un historial verificable de sesiones, eventos y participación constante.

Conclusión

Gracias por estar ahí. Por leer, por escuchar, por debatir y por cuestionar. Este reconocimiento lleva mi nombre, pero se sostiene sobre una comunidad que cree en compartir conocimiento técnico sin humo ni atajos.

Seguimos adelante. Porque todavía quedan muchas consultas mal escritas que corregir, muchos índices innecesarios que eliminar y, con suerte, algún SELECT * menos en producción. Y eso, al final, es lo que realmente importa.

Publicado por Roberto Carrancio en Otros, 0 comentarios
03
Dic
2025

SQL Server sobre Hyper-V: Buenas prácticas

Durante años, mencionar Hyper-V en una conversación sobre infraestructura provocaba cierto escepticismo técnico. Los más veteranos recordamos entornos de laboratorio donde el rendimiento era, siendo amables, discutible. Pero como casi todo en tecnología, lo que ayer parecía limitado, hoy puede ser perfectamente válido… si se configura bien.

Con la adquisición de VMware por Broadcom y los movimientos corporativos que han seguido (licencias perpetuas eliminadas, precios en alza y suscripciones forzadas), muchas organizaciones están redescubriendo Hyper-V como una alternativa seria. Y no hablamos solo de pequeñas empresas. Desde entornos de desarrollo hasta producción crítica, Hyper-V vuelve a estar sobre la mesa.

Eso sí, SQL Server no se virtualiza bien «de fábrica», da igual el hipervisor. Hay que saber lo que se está haciendo. Ya vimos en el pasado artículo cómo hacerlo correctamente con VMware vSphere, y ahora toca hablar de Hyper-V.

Aquí va la guía técnica para desplegar SQL Server en máquinas virtuales Hyper-V con garantías de rendimiento, estabilidad y escalabilidad. 

Configuración de CPU y topología NUMA

Hyper-V, como vSphere, expone a la VM una topología virtual de sockets y núcleos que debe estar alineada con la arquitectura física del host. SQL Server es sensible a NUMA, así que ignorar este detalle suele traducirse en latencias adicionales, penalizaciones en la caché de CPU y acceso a memoria remota.

Más aún si usas la edición Standard de SQL Server, con su famoso límite de 4 sockets o 24 núcleos. No es raro encontrar máquinas configuradas con 8 sockets y 1 core por socket: SQL Server solo podrá usar 4 de esos sockets. Has pagado por núcleos que están ahí, pero no puedes tocarlos.

Recomendación: configura tus VMs con pocos sockets y muchos núcleos por socket, alineado con tu licenciamiento y el hardware del host. Consulta sys.dm_os_sys_info y sys.dm_os_memory_nodes para verificar desde dentro de SQL Server si la segmentación NUMA es coherente.

Memoria: estática, dedicada y bajo control

Si hay algo que no debe activarse nunca en una VM de SQL Server en Hyper-V, es la memoria dinámica. Repite conmigo: no, nunca. Realmente no se debe activar en ningúna máquina virtual sea el hipervisor que sea. SQL Server gestiona su propia memoria, y necesita tener garantizada la cantidad asignada. La memoria dinámica provoca contracciones del buffer pool, intercambios de páginas y, en general, un rendimiento lamentable.

Recomendación: desactiva la memoria dinámica. Establece un tamaño fijo adecuado y deja que SQL Server se encargue de gestionarla internamente. Si activas Lock Pages in Memory, más razón aún, asegúrate de que esa memoria está siempre disponible. Y, por favor, no sobrecomprometas memoria física del host.

Almacenamiento: discos VHDX fijos, separados y bien asignados

La tentación de usar discos dinámicos (VHDs que crecen según se escriben datos) es comprensible… pero letal. Cada crecimiento de un disco dinámico introduce latencia, fragmentación, y pausas difíciles de diagnosticar. SQL Server no espera a nadie, y menos a que el disco “se amplíe”.

Recomendación: utiliza VHDX de tamaño fijo para todos los volúmenes que gestionen datos, logs o TempDB. Preasignar el espacio elimina imprevisibilidades y evita sorpresas desagradables durante picos de carga. Una vez dentro de la VM, formatea todos los volúmenes con unidad de asignación de 64 KB, como es debido.

Además, separa cada tipo de carga I/O: el volumen del sistema operativo no debe compartir canal con los datos, ni los logs con TempDB. En Hyper-V puedes tener hasta 4 controladoras SCSI virtuales por VM. Úsalas, asigna cada grupo de discos (datos, logs, TempDB, backups) a una controladora distinta. Esto reduce la serialización del tráfico de I/O y mejora el throughput.

Rendimiento de CPU: evitar la sobreasignación

Virtualizar no significa regalar recursos. Asignar más vCPUs de las necesarias (o más de las que el host físico puede manejar de forma eficiente) no mejora el rendimiento. Al contrario, genera colas, ready time, y tiempos de espera innecesarios en ejecución.

Recomendación: empieza con pocas vCPUs y escala si la carga lo justifica. Monitoriza el uso real con sys.dm_exec_requests, sys.dm_os_wait_stats, y contadores del sistema. Si detectas latencia por CPU o colas de scheduler, ajusta. Pero no asignes 100 vCPUs “por si acaso”.

Y sí, esto aplica también si vienes de un entorno con VMware y estás migrando, el redimensionamiento es una oportunidad para quitar lastre.

Plan de energía: alto rendimiento en host y VM

Sí, sigo viendo entornos donde el host Hyper-V está en modo Balanced. En 2025. Como si SQL Server tuviera que ahorrar batería. La realidad, el plan de energía tiene un impacto directo en la frecuencia de CPU, en los P-states y, por tanto, en la latencia.

Recomendación: configura el modo High Performance en la BIOS del host, en el sistema operativo del host Hyper-V y en el sistema operativo de la VM. Sin excepciones.

Separación lógica: cada tipo de carga, su volumen

Este punto es tan importante que lo repito, SQL Server necesita separar sus cargas. La unidad C: para el sistema. Otra para MDF. Otra para LDF. Otra para TempDB. Otra para backups. Cada uno tiene un patrón de acceso distinto: los logs son secuenciales, TempDB es salvaje y los datos tienen mezcla de lecturas aleatorias y escrituras diferidas. Mezclarlo todo en un único VHD es invitar al desastre.

Recomendación: usa discos separados para cada componente, idealmente en diferentes controladoras. Y si puedes aislar físicamente esos volúmenes en distintos LUNs o pools de almacenamiento, mejor aún.

Noisy neighbors: identificarlos y silenciarlos

En entornos compartidos, tu SQL Server puede funcionar perfectamente… hasta que otra VM empieza a hacer pruebas de estrés, un backup de 5 TB, o cualquier tarea con hambre de CPU o disco. Y entonces llegan los síntomas: consultas lentas, latencia intermitente, rendimiento errático.

Recomendación: monitoriza a nivel de host. Si no tienes visibilidad desde SQL Server, estás ciego. Herramientas como SQL Sentry o el propio Performance Monitor del host pueden ayudarte a detectar estas interferencias. Considera usar Hyper-V Resource Controls para establecer límites o reservas en CPU y memoria. Y si es una carga crítica, valora asignar un host dedicado.

Otras buenas prácticas esenciales

  • Integration Services y Guest Services: mantén las integraciones Hyper-V activadas y actualizadas. Mejoran la gestión, aceleran apagados y ayudan en procesos de backup y restauración.
  • Snapshots: úsalos como lo que son, herramientas de prueba. No son backups, y dejarlos activos durante días afecta al rendimiento. Elimina los checkpoints en cuanto ya no sean necesarios.
  • Backup consistente: asegúrate de que cualquier solución de backup en caliente (VSS-aware) esté bien integrada. Si no, el backup será tan fiable como un BACKUP LOG con el disco lleno.

Conclusión

Hyper-V ya no es el pariente pobre de la virtualización. Bien configurado, es perfectamente capaz de soportar cargas exigentes de SQL Server en producción. Pero hay que saber lo que se está haciendo: desactivar memoria dinámica, evitar discos thin, configurar adecuadamente NUMA, y vigilar el entorno como un halcón.

Para quienes vienen de VMware y están considerando el cambio (por licencias, por costes o por estrategia), muchos de los principios que explicamos en el artículo anterior siguen aplicando. Pero Hyper-V tiene su propio conjunto de ajustes críticos que no se deben pasar por alto.

SQL Server necesita recursos estables, configuraciones coherentes y visibilidad total. Y eso, en Hyper-V, es perfectamente posible.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
01
Dic
2025

Github Copilot en SSMS 22: La IA para los DBAs

Este es el primer artículo para el calendario de adviento de IA organizado por Roberto Navarro y vamos a diseccionar Github Copilot en SSMS.

El día que Microsoft anunció que GitHub Copilot se integraba directamente en SQL Server Management Studio 22, muchos levantaron la ceja. Otros directamente la perdieron. No era para menos: por fin íbamos a tener una IA context-aware en el entorno donde pasamos la mitad de nuestra vida profesional (y no, no hablo de Teams). SSMS, nuestro bastión de queries, procedimientos y dolores de cabeza mal indizados.

Hasta ahora, los que queríamos asistencia de IA teníamos que usar atajos: Visual Studio Code con extensiones, herramientas de terceros, o directamente el Copilot clásico fuera de SSMS. Pero eso suponía sacrificar contexto, perder integración y andar con más ventanas que un becario con TOC. Con SSMS 22, por fin se rompe ese ciclo. 

Pero aquí no estamos para aplaudir anuncios. Estamos para ver qué hace, qué no hace, y si de verdad vale la pena o es solo otra ronda de hype para justificar suscripciones. Y lo más importante: compararlo con lo que ya tuvimos antes y que, curiosamente, hacía algunas cosas que ahora han desaparecido.

Vamos por partes.

¿Qué significa tener Copilot en SSMS?

Cuando decimos que GitHub Copilot llega a SSMS, no hablamos de una extensión opcional. Es una integración directa, visible y oficial. No hay que instalar cosas raras ni hacer malabares. Basta con tener SSMS 22 y habilitar la funcionalidad AI Assistance desde el instalador de Visual Studio.

Una vez hecho, aparece un nuevo icono en la parte superior del editor de consultas. Desde ahí puedes iniciar sesiones de chat, generar código, hacer preguntas, recibir explicaciones o incluso pedir refactorizaciones de consultas existentes. Lo más interesante: Copilot tiene acceso al esquema de base de datos activo y a la versión de SQL. No está escribiendo a ciegas.

¿Lo mejor? No necesitas ser suscriptor premium para usarlo. Una cuenta de GitHub válida, con Copilot activo (aunque sea en plan gratuito), ya te da acceso. ¿Lo peor? La funcionalidad todavía está en preview, y eso se nota. Especialmente en detalles como la ausencia, de momento, de autocompletado inline o, la más sangrante aún imposibilidad de uso asociado a una cuenta de Github Empresarial. Pero paciencia: está en camino.

La diferencia principal respecto a usar cualquier IA comercial desde sus aplicaciones propias es que aquí la IA tiene contexto real del entorno SQL. Sabe la versión del motor, el esquema activo, las tablas y sus relaciones. No está generando código desde cero, sino con cierta conciencia del entorno en el que se ejecutará. No es un “completador inteligente”, sino un ayudante que entiende lo que tiene delante. Más o menos.

¿Qué hace (y qué no)? la lista sin adornos

Estas son las funciones que Copilot puede realizar dentro de SSMS. Y cuando digo puede, me refiero a que las he probado yo mismo, no a que lo diga una nota de prensa.

Sí, puede:

  • Generar consultas con bastante precisión, basándose en datos reales de tus tablas.
  • Leer el esquema de la base de datos conectada, incluyendo columnas, tipos de datos y claves.
  • Consultar el Query Store y ayudarte a entender por qué una consulta va lenta, con sugerencias para mejorar el plan de ejecución.
  • Refactorizar código SQL ya existente, limpiarlo o reescribirlo en versiones más legibles.
  • Explicar funciones, comandos, errores de sintaxis y diferencias entre cláusulas.
  • Acceder a datos de configuración, rendimiento y seguridad, analizarlos y sugerir cambios de configuración, hasta te da el script para hacerlo.

No, no puede (o no lo hace bien aún):

  • Ejecutar sentencias de escritura: no le pidas que realice cambios en los datos. Te da el script para que lo hagas tu pero no lo ejecuta. A diferencia de Copilot en VS Code, aquí no está tan suelto con los INSERT, UPDATE o DELETE.
  • Cambios de configuración o administración del servidor: no va a activar Query Store, ni cambiar MAXDOP, ni tocar permisos. Igual que con los datos, tampoco va a cambiar configuraciones.
  • Completar código en tiempo real como lo hace en Visual Studio Code: no hay autocompletado inline (todavía).
  • Responder rápido: no sé por qué pero el tiempo de respuesta es más lento que en otras versiones de Copilot. Hay lag, y se nota.

Experiencia real: lo que me he encontrado al usarlo de verdad

Probé Copilot en SSMS con una base de datos de desarrollo y estas son mis conclusiones, sin hype ni brocha gorda.

Primero: no cambia nada del entorno, lo cual es tranquilizador para algunos. Puedes pedir lo que quieras, que no va a tocar configuraciones ni hacer ajustes peligrosos. Si esperabas una IA que te optimice el servidor, aguanta en SSMS 21 que su copilot si lo hace.

Segundo: va más lento que Github Copilot en VS Code o Copilot de SSMS 21. Hay una latencia clara entre que haces la petición y recibes la respuesta. No lo hace inútil, pero sí menos fluido. No es para escribir en modo “tormenta de código”.

Tercero: entiende muy bien las tablas y genera consultas potentes. Le pedí un informe con agregados por mes, con filtros, joins y condiciones, y lo clavó. Pero cuando intenté que ejecutara una sentencia UPDATE… me dejó colgado. En VS Code, sí lo hace. Aquí, de momento, no.

Y cuarto: me sorprendió que puede leer del Query Store. Le pregunté por una consulta que estaba yendo lenta, y fue capaz de extraer el historial de ejecuciones y sugerirme mejoras en base a planes previos. Esto sí es diferencial. Aquí no hablamos solo de “escribe código”, sino de “ayúdame a entender el problema”. Y lo hace.

En resumen: útil, sí. Limitado, también. Pero si sabes lo que hace y lo que no, puedes sacarle mucho partido.

Ya tuvimos algo parecido (y hacía más): el Copilot de SSMS 21

Antes de que GitHub Copilot se hiciera un hueco en SSMS 22, Microsoft lanzó un experimento previo con Copilot en SSMS 21. Se quedó en Preview. También con IA generativa. Pero con una diferencia clave: este traía consigo modos de operación explícitos que controlaban qué tipo de sugerencias podía dar el asistente. Me refiero a los famosos comandos:

  • /ro – Solo lectura: consultas de lectura seguras, sin posibilidad de modificación.
  • /rw – Lectura y escritura: consultas de lectura y escritura, sin restricciones.
  • /rwa – Lectura/escritura con aprobación: como el anterior, pero requiriendo confirmación manual antes de ejecutar cambios.

La idea era brillante: si estás en un entorno sensible, puedes limitar el alcance de la IA. Si estás en desarrollo, lo abres todo. Y si estás enseñando a un junior, tienes una capa de seguridad. Más allá de la etiqueta, el asistente podía ejecutar cambios de configuración si el modo lo permitía. Le podías pedir que cambiase opciones de base de datos, configuraciones del servidor, o valores de sesión. Y lo hacía.

Esto, lo digo claro, ya no existe en la versión actual de GitHub Copilot para SSMS 22. No hay ningún modo /ro, /rw o /rwa. No hay control granular del tipo de acciones. Y por ahora, al menos en esta Preview, tampoco realiza cambios de datos, configuración ni operaciones peligrosas.

¿Más seguro? Sí. ¿Más útil para quien sabe lo que hace? No tanto.

¿Esto sustituye a un DBA? Spoiler: no

Ya veo venir la pregunta del jefe de turno: “¿Entonces con esto ya no necesitamos DBAs?”. Y la respuesta es muy sencilla: “Genial, entonces me voy de vacaciones, y cuando el plan de ejecución empiece a escalar a 300 segundos, se lo explicas al copiloto”.

Porque no, Copilot no sustituye a nadie que sepa lo que hace. Ayuda, sí. Mucho. Pero no razona como tú, no entiende tu negocio, no prioriza por impacto ni por SLA. No tiene contexto de aplicación ni de arquitectura. Si no sabes lo que haces, te puede generar código muy bien formado… pero totalmente inútil. Y eso, en SQL, suele doler.

Copilot es una herramienta. Como una moto. Puede hacerte más rápido, pero también matarte si no sabes frenar.

Copilot no sustituye a un DBA. Lo complementa. Lo acelera. Te ayuda a pensar en voz alta y aterrizar ideas complejas. Pero no valida lo que tú no entiendes. Si usas lo que sugiere sin revisarlo, eres tú el problema. Igual que cuando alguien copia un query de StackOverflow sin mirar el WHERE.

Y ojo con la privacidad, según Microsoft, los prompts, respuestas y metadatos de la sesión de Copilot en SSMS no se almacenan ni se usan para reentrenar modelos. Pero si estás en un entorno con datos sensibles, RGPD o paranoia institucional, revisa bien antes de autorizar su uso. La letra pequeña también existe para los entornos corporativos.

Otro aspecto a vigilar es la dependencia. Si todo tu equipo empieza a depender de Copilot para escribir desde SELECT hasta MERGE, corres el riesgo de formar una legión de “copipegas profesionales” que no entienden lo que ejecutan. No es culpa de la IA. Es culpa de no haber puesto límites y de pensar que una sugerencia automatizada sustituye a una formación sólida.

Recomendaciones para el uso en entornos serios

Vale, quieres usar Copilot en tu empresa. Perfecto. Pero hazlo bien.

Empieza en entornos de desarrollo. Crea un entorno de pruebas donde puedas evaluar la calidad del código generado, su rendimiento, y su adecuación a las guías internas. Establece políticas claras sobre lo que se puede y no se puede pedir a la IA (por ejemplo, nada de scripts de borrado o alteraciones sin validación humana).

Forma al equipo. No basta con decir “ahora tenemos Copilot”. Hay que enseñar a pedir bien. Un prompt claro, con contexto, con restricciones, da resultados mucho más útiles que una petición vaga.

Y, sobre todo, exige revisión humana. Todo código generado por Copilot debería pasar por una validación. No porque sea malo (a estas alturas suele ser decente), sino porque aún no hemos llegado al punto en que puedas confiar ciegamente en una máquina que nunca ha pisado producción.

Conclusión: buena idea, pero úsala con cabeza

GitHub Copilot en SSMS 22 no es humo. Es una herramienta que puede cambiar nuestra forma de trabajar como DBAs, desarrolladores y responsables de datos. Nos permite acelerar tareas, explorar soluciones alternativas y reducir el tiempo que dedicamos a repetir siempre lo mismo. Eso sí: como cualquier herramienta potente, puede ser peligrosa en manos poco formadas.

Si sabes lo que haces, Copilot te hará mejor. Si no lo sabes, sólo lo hará más rápido.

Y si alguien en tu empresa sugiere que esto puede sustituir al equipo de bases de datos, pídele que lo active en su entorno… y que pruebe a hacer tuning con la IA cuando caiga la base de datos un viernes a las 23:45.

No hay IA que arregle eso. Pero sí un DBA cabreado que se lo recordará toda la vida.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
26
Nov
2025

SQL Server sobre VMware vSphere: Buenas prácticas

La virtualización de SQL Server ha sido durante más de una década una de las estrategias más consolidadas en entornos corporativos. VMware vSphere ha jugado un papel central en ese éxito, ofreciendo una plataforma madura, estable y altamente optimizada para ejecutar cargas de trabajo críticas como bases de datos relacionales. Sin embargo, en 2025 la situación es diferente.

Desde que Broadcom cerró la adquisición de VMware a finales de 2023, el panorama ha cambiado. La transición forzada al modelo de suscripción, la retirada de licencias perpetuas y el aumento generalizado de precios han generado un malestar evidente en muchos clientes. Algunas organizaciones han iniciado migraciones hacia Hyper-V, otras han apostado por plataformas cloud y unas pocas han optado incluso por volver al metal físico para sus cargas más exigentes.

Pero en medio de esa reconfiguración estratégica, una cosa sigue siendo cierta: vSphere sigue siendo una de las plataformas más fiables para ejecutar entornos virtualizados críticos como servidores SQL Server, siempre que se configure correctamente. Y eso, precisamente, es lo que nos ocupa en esta guía.

A continuación, abordamos en profundidad las consideraciones técnicas clave para desplegar SQL Server sobre VMware vSphere en 2025, actualizando las recomendaciones oficiales a la realidad operativa actual. Porque más allá de las decisiones de licenciamiento o la política comercial de turno, lo que importa es garantizar que nuestras bases de datos funcionen con previsibilidad, rendimiento y resiliencia.

Antes de empezar, conviene señalar que la mayoría de los fundamentos que vamos a repasar están basados en la guía oficial de VMware publicada en 2019 (Architecting Microsoft SQL Server on vSphere). No obstante, han pasado seis años desde entonces, por lo que además de recuperar los puntos más relevantes, matizaremos aquellos aspectos donde la tecnología, el hardware o las prácticas de operación han evolucionado.

Diseño correcto de la máquina virtual

Uno de los errores más comunes en despliegues SQL Server sobre vSphere es asumir que la virtualización, cómo se puede redimensionar fácilmente, elimina la necesidad de una planificación detallada. Nada más lejos de la realidad. El rendimiento y la estabilidad de SQL Server dependen en gran medida de cómo se diseñe la máquina virtual así que si, podrás cambiarlo luego pero eso no quiere decir que no lo diseñes bien de primeras.

Dimensionamiento inicial (right-sizing)

A diferencia de entornos físicos, en VMware es preferible asignar sólo los recursos que la carga realmente necesita. Asignar más CPU o RAM de la necesaria puede generar efectos negativos: contención, mayor coste de scheduling, uso ineficiente de licencias, o incluso, aunque pueda ser contraintuitivo, peor rendimiento. Una VM con más vCPU de las que necesita puede sufrir más Ready Time, más latencia y menos rendimiento.

Para dimensionar correctamente, conviene recopilar datos de uso real de CPU, memoria y disco mediante DMVs, Performance Monitor o herramientas de observabilidad (SQL Sentry, vRealize Operations). A partir de ahí, se puede asignar el número adecuado de vCPU y memoria, ajustando posteriormente según carga.

Configuración de CPU y NUMA

Núcleos por socket: impacto técnico y de licenciamiento

La edición Standard de SQL Server impone límites que no siempre se respetan al definir una VM: máximo 4 sockets o 24 núcleos. Por tanto, es frecuente encontrar configuraciones ineficientes: por ejemplo, una VM con 8 sockets y 1 core por socket, que solo permite el uso de 4 sockets con un núcleo cada uno, aunque se hayan asignado 8 núcleos.

Lo recomendable es agrupar los núcleos virtuales en menos sockets: por ejemplo, 1 socket con 8 cores, o 2 sockets con 12. Esto permite que SQL Server aproveche todos los recursos asignados sin restricciones de licenciamiento.

Consideraciones NUMA

Cuando una VM supera los recursos de un nodo NUMA físico (CPU o memoria), se producen accesos a memoria remota, lo que introduce latencia física. SQL Server es muy sensible a este comportamiento así que tenlo en cuenta.

VMware detecta la topología NUMA del host y crea configuraciones vNUMA equivalentes, pero esto solo es posible si la VM tiene más de 8 vCPU (configurable). En cualquier caso, es necesario verificar que la asignación real de nodos NUMA es coherente, tanto desde el visor de recursos del host como desde dentro de SQL Server (por ejemplo, con sys.dm_os_memory_nodes).

Asignación y gestión de memoria

Evitar el overcommit de memoria

En entornos VMware es posible sobreasignar memoria física, confiando en mecanismos como ballooning o swapping para equilibrar el uso. Pero esto es completamente desaconsejado para máquinas que ejecutan SQL Server, ya que su gestión interna de memoria (buffer pool, cache) depende de una disponibilidad constante.

La práctica recomendada es reservar memoria para la VM (memory reservation = memory size) y evitar que el host pueda utilizar parte de esa RAM para otros fines. En ESXi modernos, la opción de Transparent Page Sharing (TPS) está deshabilitada por defecto, lo que refuerza la necesidad de no sobrecomprometer recursos.

Configuración dentro de SQL Server

Dentro de la instancia, es imprescindible limitar la memoria máxima (max server memory) para evitar que el sistema operativo se quede sin recursos. Hay que tener un especial cuidado al habilitar lock pages in memory, JAMÁS se debe activar si el balloning está activado para esa VM o puede producir errores. 

Siguiendo con estas configuraciones, el uso de large pages (Trace Flag 834) puede mejorar el rendimiento en sistemas con mucha RAM, pero es muy delicado y requiere pruebas específicas. De todas formas no seré yo quien os recomiende una configuración que ni Microsoft recomienda…

Almacenamiento y controladoras

Cuando se crean discos virtuales (VMDKs) para una VM, VMware permite elegir entre discos de tamaño fijo (thick provisioned) o dinámico (thin provisioned). Aunque el aprovisionamiento dinámico puede ahorrar espacio a corto plazo, introduce fragmentación y penalizaciones de rendimiento a medida que el disco crece.

En entornos SQL Server, donde la carga de I/O es constante y predecible, el uso de discos thin puede generar latencia adicional, sobre todo en sistemas de almacenamiento que no gestionan bien el crecimiento dinámico.

La recomendación es clara, utilizar discos de tamaño preasignado (thick eager zeroed) para todos los VMDKs que manejen datos, logs o TempDB. Este tipo de disco se crea completamente al aprovisionar la VM, evitando operaciones de escritura adicionales durante el uso. Esta práctica garantiza un mejor rendimiento sostenido, especialmente en entornos con IOPS elevados, y reduce el riesgo de fragmentación interna del datastore

Separación de discos y uso de PVSCSI

Una práctica consolidada es separar los distintos tipos de archivos de SQL Server en VMDKs distintos: sistema operativo, base de datos, logs, TempDB. Esto no solo mejora el rendimiento, también facilita la gestión de snapshots, backups y análisis de uso.

En cuanto a la controladora, VMware recomienda usar PVSCSI en lugar de LSI Logic SAS para los discos de datos. PVSCSI ofrece mayor profundidad de cola (hasta 256) y menor uso de CPU. La configuración ideal combina:

  1. LSI Logic SAS solo para la unidad C:\
  2. Varias controladoras PVSCSI adicionales para datos, logs y TempDB, separadas si es posible.

Compatibilidad con NVMe

Aunque los discos NVMe han ganado presencia en datacenters en los últimos años, las recomendaciones no cambian: PVSCSI sigue siendo preferible por compatibilidad, madurez y soporte. Solo si se trabaja directamente con hardware o almacenamiento NVMe puede valorarse otra configuración, siempre tras validación en laboratorio.

Instantáneas (snapshots): limitaciones y riesgos

Los snapshots de vSphere son herramientas útiles para pruebas y cambios puntuales, pero no deben utilizarse como método de backup. En SQL Server, los discos delta que crean los snapshots generan penalizaciones de rendimiento progresivas, especialmente en entornos con alto volumen de escritura.

Es frecuente que un snapshot olvidado de semanas cause degradaciones difíciles de diagnosticar. Si hay que usarlos, deben eliminarse en horas, no días. Y siempre debe preferirse una estrategia de backup basada en herramientas nativas o soluciones de backup empresarial compatibles con SQL Server.

Red y conectividad

SQL Server puede requerir un uso intensivo de red, especialmente en escenarios con alta concurrencia, réplicas, Always On o transacciones distribuidas.

Las interfaces de red deben ser siempre VMXNET3, que ofrecen mejor rendimiento y menor latencia que E1000. Además, se recomienda activar Receive Side Scaling (RSS) tanto en el sistema operativo como en las VMware Tools, para distribuir la carga de red entre múltiples núcleos de CPU.

Si se trabaja con grandes volúmenes de datos entre nodos (como en grupos de disponibilidad o replicaciones), debe garantizarse que la infraestructura física y virtual está optimizada para latencia baja y alto throughput. 

Por ejemplo, es una buena práctica usar una VLAN e interfaz de red (física y virtual) dedicada para la comunicación entre servidores SQL, o para la conexión con los servidores de copias de seguridad.

Configuración de energía

Cuando hablamos de servidores críticos debemos primar el rendimiento a la eficiencia energética y esto implica establecer un plan High Performance en todos los niveles

El plan de energía es una de las configuraciones más olvidadas (si aun en 2025), pero con mayor impacto. Por defecto, ESXi y Windows Server pueden utilizar políticas de ahorro de energía (Balanced), que reducen la frecuencia de CPU o introducen cambios de estado (P-states) perjudiciales para cargas sensibles.

La recomendación es clara: habilitar el modo High Performance en tres capas:

  1. BIOS del host físico.
  2. Política de energía de ESXi.
  3. Plan de energía dentro del sistema operativo invitado.

Esta configuración reduce la latencia de respuesta de la CPU y evita throttling no deseado. En pruebas reales, he notado mejoras de entre el 10 y el 15% en rendimiento solo con una buena configuración de energía.

Disponibilidad y recuperación

Garantizar la disponibilidad de una instancia de SQL Server virtualizada no se limita a activar vSphere HA o a desplegar un grupo de disponibilidad. Exige entender cómo interactúan las funcionalidades de VMware con las tecnologías de alta disponibilidad del propio SQL Server, y decidir cuál debe ser el punto de recuperación (RPO) y el tiempo de recuperación objetivo (RTO) para cada tipo de fallo.

Alta disponibilidad en la capa VMware

VMware proporciona mecanismos propios de alta disponibilidad y movilidad de cargas que pueden complementar (o incluso entrar en conflicto con) las estrategias nativas de SQL Server:

  • vSphere HA permite el reinicio automático de una VM en otro host del clúster cuando se detecta un fallo físico. No ofrece continuidad de servicio inmediata, pero sí reduce el downtime sin intervención manual. Es transparente para el sistema operativo y para SQL Server.
  • vSphere FT (Fault Tolerance) proporciona replicación síncrona a nivel de VM y failover instantáneo sin pérdida de estado. No está soportado para máquinas con más de 8 vCPU (en la mayoría de versiones actuales) y no es compatible con algunos escenarios de licenciamiento de SQL Server. Es útil solo en casos muy concretos y no se recomienda como estrategia principal de HA para SQL.
  • vMotion permite migrar en caliente una VM entre hosts sin apagado, útil para mantenimiento planificado o balanceo. Sin embargo, en cargas intensivas (como operaciones de backup, reindexación o grandes transacciones), la migración puede introducir latencias temporales. Aunque no genera caída del servicio, puede afectar al rendimiento en momentos críticos.
  • DRS (Distributed Resource Scheduler) balancea dinámicamente la carga entre hosts según consumo de recursos. Esto puede provocar movimientos frecuentes de la VM si no se definen reglas adecuadas. 

En entornos con SQL Server, es necesario evaluar cuidadosamente el impacto de vMotion y DRS en instancias críticas. Mover una VM durante una operación intensiva puede degradar el rendimiento o generar latencia adicional. Se recomienda definir reglas de afinidad o exclusión para evitar migraciones no deseadas. 

Consideraciones de diseño

A la hora de planificar una solución de alta disponibilidad para SQL Server sobre VMware, es fundamental definir el tipo de fallo que se quiere cubrir:

  • Fallo físico del host: vSphere HA es suficiente si se acepta un reinicio de VM.
  • Fallo de software en el sistema operativo o SQL Server: requiere HA a nivel de SQL Server (AG, FCI).
  • Fallo del datastore: debe cubrirse mediante almacenamiento redundante (vSAN, replicación SAN/NAS).
  • Fallo completo del datacenter: implica solución de recuperación ante desastres (DR), normalmente con réplicas geográficas y procedimientos definidos de failover manual o automático.

Es importante destacar que las soluciones de VMware y SQL Server no son excluyentes, pero deben coordinarse cuidadosamente para evitar conflictos: por ejemplo, no tendría sentido proteger una FCI solo con vSphere HA, o dejar que DRS migre réplicas sincronizadas entre hosts indiscriminadamente. En casos en los que se implementan soluciones HA de SQL Server se recomienda definir reglas de afinidad y exclusión para que las máquinas implicadas en el HA no compartan host físico.

También hay que considerar el licenciamiento: algunas ediciones de SQL Server requieren licencias activas en todas las réplicas del clúster, incluso si solo una está activa (según el uso que se haga). Además, ciertos entornos requieren asegurar que las réplicas pasivas no procesan cargas activas para beneficiarse de ventajas en licencias de Software Assurance.

Vecinos ruidosos

Uno de los retos más infravalorados en la virtualización de cargas críticas como SQL Server es el efecto de otras VMs compartiendo el mismo host físico, conocidas comúnmente como “noisy neighbors” (vecinos ruidosos).

Una máquina virtual que consume picos de CPU, I/O o memoria puede afectar negativamente a otras VMs en el mismo host, especialmente si no hay control de calidad de servicio (QoS) o reservas definidas. Los síntomas suelen incluir:

  • Latencia intermitente en consultas.
  • Variabilidad en tiempos de respuesta bajo carga constante.
  • Aumento de CPU Ready Time o Co-Stop sin incremento aparente de carga en SQL Server.

Para detectar estos problemas, se requiere visibilidad más allá del sistema operativo invitado. Herramientas como vRealize Operations, SQL Sentry o VMware Aria Operations permiten identificar VMs que saturan recursos compartidos, y correlacionar ese uso con degradaciones de rendimiento en las instancias afectadas.

En este caso las recomendaciones son:

  • Establecer reservas mínimas de recursos para VMs críticas.
  • Aplicar affinity/anti-affinity rules para separar cargas pesadas o sensibles.
  • Evitar que SQL Server comparta host con VMs que realizan tareas de backup, ETL o pruebas automatizadas en horarios críticos.
  • Monitorizar periódicamente la actividad del host para detectar comportamientos anómalos.

En entornos donde se requiere máxima previsibilidad (banca, OLTP de alto rendimiento, entornos de pricing), puede incluso justificarse la dedicación exclusiva de host para una o varias VMs SQL Server.

Versiones de hardware y VMware Tools

Mantener actualizadas tanto la versión de hardware virtual como las VMware Tools es esencial para acceder a nuevas funcionalidades, mejorar el rendimiento y garantizar el soporte oficial.

En 2025, la versión mínima recomendada es hardware version 19 (ESXi 7.0), aunque lo ideal sería estar en versión 20 u 21 si se usa ESXi 8.x. Las VMware Tools deben actualizarse de forma coordinada tras cambios de versión o parches del host.

Monitorización y observabilidad

Las métricas estándar de vSphere no siempre ofrecen suficiente visibilidad sobre los cuellos de botella que afectan a SQL Server. Por ello, se recomienda utilizar herramientas especializadas que permitan analizar desde la capa de hipervisor hasta el motor de base de datos:

  • SQL Sentry (SolarWinds): ofrece no solo métricas de SQL Server sino también propias del entorno virtual.
  • vRealize Operations: para el análisis de capacidad, planificación y rendimiento.
  • Perfmon + DMVs: exclusivo para el análisis desde dentro de la VM.

Indicadores como CPU Ready Time, Co-Stop, latencia de I/O, uso de memoria o crecimiento de snapshots deben estar controlados de forma continua.

Conclusión

La virtualización de SQL Server sobre VMware sigue siendo, en 2025, una estrategia plenamente válida para cargas de misión crítica. Pero su éxito depende de un diseño cuidadoso, de un conocimiento profundo del comportamiento del motor SQL y de una integración adecuada con las funcionalidades del hipervisor.

Los errores más comunes (malas configuraciones NUMA, exceso de vCPU, uso de snapshots como backup, planes de energía inadecuados) pueden evitarse si se siguen las prácticas que hemos repasado. Esta guía pretende servir como base técnica de referencia para garantizar que cada instancia virtualizada de SQL Server funcione con la previsibilidad, rendimiento y fiabilidad que un entorno de producción exige.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, Rendimiento, SQL Server, 1 comentario
19
Nov
2025

Nueva caché de seguridad en SQL Server 2025

Llevamos ya tiempo con la preview de SQL Server 2025 probando todas las novedades. La lista es larga y, a veces, cuesta distinguir entre lo realmente útil y lo puramente decorativo. Entre tanto brillo marketiniano, hay una mejora de la que no se ha hablado, que muchos pasarán por alto sin comprender las implicaciones, pero que a mi me ha hecho sonreír y decir: “Ya era hora”. Os hablo de la nueva capacidad de invalidar cachés de seguridad de forma específica por inicio de sesión en SQL Server 2025. Y sí, es tan buena como suena.

¿Qué es esto de la caché de seguridad?

Antes de meternos en harina, conviene recordar qué es exactamente esa “caché de seguridad” que ahora Microsoft ha afinado. Cuando un usuario se conecta a SQL Server, el motor evalúa qué permisos tiene para acceder a objetos, ejecutar procedimientos, ver datos… ya sabéis, lo básico para evitar que todo sea un buffet libre de SELECT * FROM SensitiveTable.

Como no somos tontos (y SQL Server tampoco), esta validación no se repite cada vez que alguien lanza una consulta. Sería un suicidio en términos de rendimiento. En su lugar, SQL Server guarda esa información en memoria (en la famosa security cache) y la reutiliza mientras no haya cambios que invaliden su contenido.

¿El problema? Hasta ahora era muy sensible. Si cambiabas cualquier permiso de cualquier usuario (cambio de permisos, modificación de roles, o revocar un acceso), se eliminaban todas las entradas DE TODOS LOS USUARIOS. Esto, por supuesto, tiene efectos inmediatos en el rendimiento de cualquier sesión abierta, aunque no tuviera nada que ver con el cambio.

Vamos, que tirábamos la caché como quien reinicia un servidor por si acaso: por pura desesperación.

SQL Server 2025 trae cordura: invalidación específica por login

Con la llegada de SQL Server 2025, se acabó el “todo o nada”. Ahora, cuando se invalidan entradas de la caché de seguridad debido a un cambio en los permisos, el sistema es lo bastante listo como para borrar solo las entradas correspondientes al login afectado. El resto permanece intacto.

Esto supone una mejora directa en varios frentes. Para empezar, reduce el impacto de cualquier cambio de seguridad. No hay invalidaciones masivas innecesarias, no se resienten las sesiones de otros usuarios, y la CPU no se dispara validando de nuevo cientos o miles de entradas de permisos para conexiones que no han cambiado ni una coma de sus privilegios.

¿Por qué esto importa? Rendimiento, escalabilidad y menos sustos

Puede parecer que un cambio de estas características no tiene mucha importancia, y así es entornos con pocos usuarios y permisos bastante genericos. Pero cuando el volumen de usuarios y la granularidad de los permisos son considerables, la diferencia entre invalidar toda la caché de seguridad y hacerlo de forma selectiva puede marcar la diferencia. En entornos con cientos o miles de sesiones concurrentes, la diferencia es tan evidente como entre ejecutar SELECT con un índice… o sin él.

Antes, un cambio puntual en los permisos podía convertirse en una mini tormenta de validaciones. La CPU subía, la latencia aumentaba, y tú te encontrabas explicando por qué un GRANT a las 9:30 había dejado la aplicación más lenta que un Access con macros durante unos minutos. Todo eso queda en el pasado con esta nueva implementación.

Ahora, si revocas un permiso a un usuario que ya estaba conectado, SQL Server se limita a eliminar sus entradas específicas de la caché. El resto de usuarios ni se enteran. Y tú tampoco tendrás que revisar gráficos de rendimiento preguntándote qué demonios ha pasado.

Cambios de roles, miembros de grupos y lo que siempre duele

Uno de los escenarios donde esto brilla especialmente es cuando se hace una modificación en roles o membresías de grupos. Añadir o quitar a alguien de un db_datareader, por ejemplo, solía ser sinónimo de purgar toda la caché de seguridad.

Con SQL Server 2025, eso se acabó. La limpieza de la caché se ciñe a ese login concreto, incluso si el cambio afecta a una membresía en roles de servidor o roles personalizados. Menos interrupciones, menos recompilaciones internas, y más estabilidad.

Que sí, que aún quedan muchos elementos que provocan recompilaciones y limpiezas de caché que no siempre tienen sentido, pero al menos aquí han puesto orden en una de las áreas más olvidadas por el motor en versiones anteriores.

¿Cómo saber si está funcionando?

No hay un nuevo DMV mágico que diga “estás disfrutando de la nueva caché de seguridad personalizada”, pero si monitorizas el uso de CPU y el acceso concurrente durante cambios de permisos, deberías notar una mejora clara. Sobre todo en sistemas con mucha actividad concurrente y una gestión de seguridad activa.

Y si eso no te vale y quieres verlo con tus propios ojos siempre nos quedarán los eventos extendidos, esa magnífica herramienta que lo captura todo. Puedes crear una sesión que capture los nuevos eventos “login_token_cache_hit” que se producen cuando el token de la caché de seguridad sigue activo y el evento “login_token_cache_miss” que es cuando el token de la caché no es válido y hay que generar una nueva entrada.

Demo caché de seguridad 

Vamos a comprobar que esto realmente funciona. Para ello tenemos nuestros logins con ID 267 y 268 y vamos a crear una sesión de xEvents que capture los eventos que hemos comentado antes:

 CREATE EVENT SESSION [SecCacheMonitoring] ON SERVER 
ADD EVENT sqlserver.login_token_cache_hit(
    ACTION(package0.callstack,package0.callstack_rva,sqlserver.session_id)
    WHERE ([package0].[equal_uint64]([login_id],(267)) OR [package0].[equal_uint64]([login_id],(268)))),
ADD EVENT sqlserver.login_token_cache_miss(
   ACTION(package0.callstack,package0.callstack_rva,sqlserver.session_id,sqlserver.username)
    WHERE ([package0].[equal_uint64]([login_id],(267)) OR [package0].[equal_uint64]([login_id],(268))))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Lo primero que vamos a hacer es borrar la caché de seguridad:

DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')
Ahora, con una ventana de consulta en modo SQLCMD vamos a generar las dos conexiones de ambos logins:
:CONNECT SERVIDOR -U Login2 -P VeryStr0ngP@ssword01! -C
SELECT @@VERSION;
GO

:CONNECT SERVIOR -U Login3 -P VeryStr0ngP@ssword01! -C
SELECT @@VERSION;
GO
:QUIT

Como hemos borrado la caché, estas dos primeras entradas generan un evento “login_token_cache_miss”, no existe registro en la caché. 

Caché seguridad miss

Pero, si volvemos a conectarnos veremos ya los hit, es decir ha utilizado el token existente en caché

caché seguridad hit

Ahora vamos a cambiar los permisos de uno de los logins

GRANT VIEW SERVER STATE TO Login2

Y al volver a conectar veremos solo uno de los dos logins tiene el miss y el otro mantiene su token válido (evento hit). Además veís en la captura que yo he añadido tambien los eventos “security_cache_login_timestamp_increment” a mi captura de eventos, que me indica cuando se ha producido un cambio de permisos.

cache seguridad mejorada

¿Qué implicaciones tiene para nosotros como DBAs?

Básicamente, nos devuelve un poco de control. Ahora podemos aplicar cambios de seguridad sin tener miedo a provocar un alud de recompilaciones y penalizaciones de rendimiento. Se acabó el tener que programar revocaciones de permisos fuera del horario laboral o acompañarlas de una explicación de daños colaterales.

También nos da más seguridad en entornos de desarrollo y pruebas. Podemos simular escenarios de cambios de permisos sin el temor a que medio entorno colapse por culpa de una caché global destruida innecesariamente.

Eso sí, no todo es perfecto. La documentación oficial todavía no entra en muchos detalles sobre cómo se comporta esta nueva caché con escenarios complejos de impersonación (EXECUTE AS), certificados o permisos a nivel de esquema. Habrá que investigar (y ya lo haré en otro artículo si me lo pedís) si este comportamiento selectivo se extiende también a esos casos.

Conclusión

La invalidación selectiva de la caché de seguridad en SQL Server 2025 es una mejora tan lógica que sorprende que no estuviera ya implementada hace años. Pero aquí está, y funciona como debe. Nos da más precisión, menos impacto colateral y permite cambios de seguridad sin temor a convertir el servidor en una verbena de validaciones.

Como siempre, no es magia. Si haces cambios absurdos o con prisas, te seguirás metiendo en líos. Pero al menos, ahora, el motor te lo pone un poco menos difícil. Y eso, en este mundo de permisos, roles y DBA que no duermen, ya es bastante.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
05
Nov
2025

El hardware se abarata, el licenciamiento de SQL Server no

Hace poco me compré un portátil nuevo. Un equipo serio, de esos con más núcleos que sentido común y potencia suficiente para levantar sin despeinarse un entorno de desarrollo completo con SQL Server, BI y lo que se le ponga por delante. Vamos, lo que necesito para las demos en los eventos. Precio: unos 2000€. Hasta aquí, todo bien.

Pero al mirar los procesadores disponibles (Ryzen con 16 o 24 núcleos, Intel con 20 y más RAM que la que tenía tu último servidor físico en producción) no pude evitar pensar: si alguien quiere usar esto para algo serio, ¿cómo lo licencia?

Y ahí es donde empieza el problema. Porque el precio del hierro ha bajado, pero el coste del licenciamiento de SQL Server sigue atascado en 2012. O antes.

El espejismo de la democratización

Nos han vendido la moto de que la informática se ha democratizado, que cualquiera puede montar un sistema potente por poco dinero, que digitalizarse es barato. Y en parte es verdad… hasta que levantas la alfombra del licenciamiento.

Cualquier pyme, autónomo o pequeño despacho que hoy quiera informatizar su gestión (pongamos que por exigencias tan poco opcionales como VERIFACTU) probablemente lo hará con lo que tiene a mano: un PC sobremesa moderno, o a lo sumo una torre decente con componentes actuales. Las pequeñas empresas no tienen presupuesto para servidores.

El problema es que hoy incluso un sobremesa “modesto” puede tener un procesador de 16 núcleos físicos y 128 GB de RAM por menos de 1500€. Y en ese momento SQL Server te sonríe… con su sonrisa de tiburón.

SQL Server Standard: paga por core, sufre por diseño

Si quieres usar SQL Server Standard en producción, aunque sea solo para almacenar facturas y cuatro tablas más, y te vas al modelo de licenciamiento por núcleo, prepárate: cada core te cuesta unos 2000 dólares. Sí, da igual que tu software solo use un hilo. Pagas por el número de núcleos visibles al sistema operativo, no por el uso real.

Y aquí viene lo bueno: en un PC moderno que no sea una patata, lo normal es que haya 12, 16 o 24 núcleos físicos (con el doble de vCores). Haz números. Eso son 24.000, 32.000, 48.000 o más euros solo en licencias, sin contar soporte, copias, backups, ni nada más.

Lo que iba a ser una digitalización económica se convierte en un agujero financiero. Y claro, muchos acaban optando por soluciones “temporalmente tolerables” como usar la versión Express… hasta que chocan de frente con sus limitaciones.

Express Edition: demasiado limitada para tomársela en serio

Sí, SQL Server Express es gratuita. Pero su techo de 10 GB por base de datos, 1 GB de RAM utilizable por instancia y uso de un único core lógico la hacen útil para pruebas, no para operar un negocio que mínimamente se tome en serio sus datos.

¿Que quieres hacer informes? Prepárate para sufrir. ¿Que tienes un CRM o un ERP que genera logs o almacena históricos? En dos años estarás exportando datos a Excel para aligerar. ¿Que necesitas rendimiento? Olvídalo.

La Express está bien para entornos de aprendizaje o microproyectos. Pero no está pensada para escenarios empresariales reales, por pequeños que sean.

La trampa del licenciamiento Server + CALs

Aquí algunos intentan una vía alternativa: el modelo de licenciamiento Server + CALs. Y sí, puede ser más asequible si solo tienes unos pocos usuarios y no quieres pagar por cada core.

Pero Microsoft te pone dos límites claros con SQL Server Standard bajo este modelo:

  • Máximo 24 núcleos virtuales visibles.
  • Máximo 128 GB de RAM utilizables.

Y aquí volvemos al drama. Porque un PC de 2025, sin ser nada del otro mundo, puede traer más de 12 núcleos físicos que son 24 virtuales (vCores) fácilmente. Y cuando eso pasa, no puedes usar Server + CALs legalmente. Te obligan a licenciar por core, aunque no necesites ni el 10% de los recursos. Maravilloso, ¿verdad?

Y no, no puedes decir “bueno, entonces limito el uso de cores desde el BIOS o desde el sistema operativo”. Eso no es legalmente vinculante para Microsoft. Si la CPU física tiene 32 núcleos, los vas a pagar todos. Así funciona el modelo de licencias.

En la nube también duele: SQL Server frente a PostgreSQL

Alguien podría pensar: “Vale, el licenciamiento físico es duro, pero si me voy al cloud me quito ese problema de encima, ¿no?”. Bueno… no exactamente. En la nube sigue siendo caro, y en algunos casos, directamente ridículo.

Vamos con cifras reales y actuales, para no caer en sensaciones vagas:

En Azure, una base de datos SQL con 8 vCores cuesta unos 893 dólares al mes. En el mismo entorno, una base de datos administrada de PostgreSQL con 8 vCores cuesta 123 dólares al mes. No es una diferencia. Es un abismo. Con lo que pagas por SQL puedes montar 7 PostgreSQL distintos y aún te sobra para un par de backups con redundancia geográfica.

Y si nos vamos a AWS, el panorama no mejora. Una instancia RDS de SQL Server con 16 vCores y 64 GB de RAM (db.m5.4xlarge) cuesta alrededor de 7.100 dólares mensuales. Sí, has leído bien: más de siete mil dólares al mes. Mientras tanto, la misma configuración con PostgreSQL cuesta 2.423 dólares mensuales. Casi tres veces menos.

Lo importante aquí no es solo el número. Es lo que implica: SQL Server no escala bien en costes. A mayor capacidad, mayor diferencia, y no precisamente a favor. PostgreSQL, en cambio, mantiene un coste racional y predecible, lo que lo hace mucho más viable en entornos que necesiten crecer sin hipotecarse.

Esto deja muy claro por qué tantos arquitectos de datos y CTOs están migrando workloads al open source. No porque les guste complicarse la vida, sino porque el presupuesto manda. Cuando el coste de mantener una base de datos supera al de todo el resto de la arquitectura, hay un problema, y no es técnico.

¿Qué opciones de licenciamiento tiene una pyme? Pocas, y ninguna es buena

Después de todo lo dicho, lo razonable es preguntarse: “¿Qué hago si necesito SQL Server, tengo un hardware moderno y no quiero fundirme el presupuesto en licencias?”

Pues no tienes muchas alternativas, realmente no hay una opción buena, solo algunas menos malas.

Primera opción de licenciamiento: SQL Express

Esta es la más obvia, SQL Express es gratis, sí, pero está muy limitada. Para empresas pequeñas con muy pocos datos puede ser una opción pero siempre con la vista puesta en sus límites. No solo hablo del hardware, que ya impone unos límites considerables (solo usa 4 vCores, 1 Gb de RAM y las bases de datos no pueden superar los 10Gb), sino que le faltan muchas características como el agente de SQL Server, SSIS, SSAS, etc… 

Aunque también es cierto que seguramente no necesites las aplicaciones de ETL o analítica y que la limitación del agente la puedas salvar ejecutando SQLCMD con tareas programadas en el programador de tareas de windows.

Segunda opción de licenciamiento : Licencias Server + CAL

La segunda opción es licenciar tu SQL Server Standard por Server + CALs… si puedes. Esto solo aplica a SQL Server Standard y si tienes un número limitado de usuarios bien controlado. Y no se aplica a entornos públicos, web apps o APIs abiertas. Si tu escenario es cerrado y sabes exactamente cuántos usuarios acceden, podría salirte más barato, unos 900€ la licencia del servidor SQL Server. Pero cuidado, porque CALs también cuestan y hay que contarlas bien, cada usuario que se conecte necesitará su CAL de aproximadamente 200€.
Pero recuerda, esta opción solo es posible si tu máquina tiene menos de 24 vCores. Y si te preguntas si puedes crear una máquina virtual con menos vCores para ahorrar dinero tengo una mala noticia, no es tan sencillo.
Para el licenciamiento de máquinas virtuales Microsoft exige licenciar todos los vCores de la máquina física así que estaríamos en las mismas. Por suerte hay un clavo ardiendo al que puedes agarrarte, es posible licenciar solo los vCores de la máquina virtual si, y solo si, contratas Software Assurance (SA). Este servicio es una suscripción de pago anual que te da derecho, además de a pagar solo por los vCores de la VM, a actualizaciones de versiones de SQL Server. Lo malo es que aquí no podemos hablar de precios, Microsoft no los comparte y tendrás que negociarlos con tu partner de licencias (suele costar anualmente entre un 20 y un 30% del coste de las licencias).

Tercera opción de licenciamiento: Cloud y pago por uso

Ya hemos visto que el coste de la nube no es barato, aun así, el pago mes a mes puede ser más fácil de asumir que el desembolso total de las licencias de una sola vez. Además, si tienes pocos requisitos de recursos, en Azure hay bases de datos sin servidor desde 5€/mes, con unos recursos muuuuy limitados, claro.

 Quedaría otra opción, abandonar SQL Server y mirar a la competencia pero eso ya no es tan sencillo, al menos para proyectos o desarrollos existentes. Oracle no es una opción, su coste por licencia es también por core y cuesta más del doble que SQL Server, pero no es la única alternativa.

PostgreSQL, MariaDB, o incluso SQLite: la fuga silenciosa

Cada vez más desarrolladores están abandonando SQL Server. No porque no funcione bien (que lo hace maravillosamente bien), ni porque no tenga features potentes (que las tiene geniales). Sino porque ya no es viable para ciertos escenarios.

PostgreSQL y MariaDB no imponen estas barreras. No cobran por core. Tampoco limitan la RAM. No te obligan a licenciar el procesador entero si solo usas dos hilos. Y, sinceramente, para el 80% de los casos de uso en empresas pequeñas, hacen el trabajo igual.

Eso si, que PostgreSQL o MariaDB no cobren por licencias no significa que sea gratis.

Porque cuando eliges PostgreSQL o MariaDB, te llevas el motor, pero no el soporte. Ni la monitorización. Ni el clúster. Tampoco la estrategia de backups. Ni la restauración en caliente. Todo eso hay que construirlo, mantenerlo… o pagarlo a una tercera empresa que lo haga.

Y aquí es donde muchas veces la factura no es tan diferente a SQL Server. Solo que el dinero no se va a Microsoft, sino a consultoras especializadas, soporte de terceros o a una inversión de tiempo interno brutal que acaba saliendo más cara de lo previsto.

También hay que reconocerlo, PostgreSQL tiene una curva de aprendizaje considerable, sobre todo si vienes de SQL Server. Lo que antes resolvías con Management Studio ahora implica línea de comandos, pg_dump, systemd, y a menudo, búsqueda en foros. Y que no te dé por hacer un clúster HA sin una herramienta externa, porque ahí es donde empiezas a pagar con sangre o con suscripciones.

Así que sí, hay motivos para migrar. Pero que no te vendan que todo es gratis. Porque no lo es. Y a veces, cuando te das cuenta, ya estás hasta el cuello de migración, y ni puedes volver atrás ni puedes pagar el camino nuevo.

Conclusión

La paradoja sigue ahí. El hardware moderno ha democratizado el acceso a CPUs potentes, pero SQL Server sigue licenciado como si cada core fuese un diamante. El resultado: una tecnología excelente, pero cada vez más difícil de justificar fuera de entornos que puedan asumir ese coste sin pestañear.

Las PYMEs, los autónomos y cualquier organización que pretenda informatizarse en serio sin vaciar su cuenta bancaria se topan con un muro invisible: el licenciamiento. Un muro que no distingue entre portátil, sobremesa o servidor, y que tampoco afloja si te mudas a la nube.

Y sí, SQL Server 2025 está en puertas, con la Release Candidate ya disponible. Pero no parece que el modelo de licencias vaya a cambiar. Ojalá me equivoque y Microsoft suba ese límite absurdo de 24 vCores para el Server + CAL. Pero no creo.

Mientras tanto, PostgreSQL y compañía siguen ganando terreno. No por ideología, sino por supervivencia económica.

Y si esto te parece exagerado, revisa tu próxima factura de Azure o AWS. O tu presupuesto para licencias on-prem. Verás que la exageración no está en el artículo. Está en el modelo.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios