cloud

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!

Ene

2026

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.

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.

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.

Oct

2025

Especial Halloween. El marrón que todo DBA ha sufrido

¿Qué Halloween da miedo? Será para los que no han tenido que restaurar un backup en producción y estaba corrupto, con el jefe respirándoles en la nuca y un SLA expirando más rápido que el café enfriándose.

Los verdaderos horrores no salen en películas. Se ejecutan en nuestros servidores.

Si el año pasado nos pusimos nostálgicos para hablar del problema de Halloween original, hoy vamos a hablar de jobs fallidos, bloqueos eternos, desarrolladores con acceso a sysadmin, y scripts “probados en otro entorno”. Marrones que un DBA conoce muy bien. Marrones que no se borran con un ROLLBACK.

Definición técnica

MARRÓN (noun)

Término operativo usado en entornos técnicos para describir cualquier tarea, incidente o requerimiento que:

No estaba prevista.
Nadie quiere hacer.
Tiene alta visibilidad y cero documentación.
Requiere acción inmediata (generalmente ayer).
Y suele implicar que el culpable eres tú, aunque no tengas ni idea de qué ha pasado.

Roles asociados:

Enmarronador (BrownDispatcher): Individuo que asigna el marrón con una sonrisa, un café en la mano o un “esto es rápido”. Suele tener cargo, pero no responsabilidad.
Enmarronado (Browned): Víctima del proceso de asignación. También conocido como “el de SQL” o “el que sabe”. No necesariamente tiene culpa, pero sí marrón.
Buscamarrones (BrownFinder): Persona que se ofrece voluntaria “para aprender” o “echar una mano”. A menudo desaparece misteriosamente cuando el marrón explota.
Comemarrones (BrownEater): DBA veterano que se ha comido tantos marrones que ya solo le quedan dos emociones: resignación y café.

Importante:

Una vez asignado, el marrón es de tu propiedad exclusiva. No importa si lo originó otro, si viene sin especificaciones o si “funcionaba en dev”. El sistema ha hablado. Eres el enmarronado.

El marrón flotante: la petición que no llega (pero llegará)

Es lunes y alguien menciona “tenemos que mirar lo del rendimiento del ERP” mientras tú estás con otras 40 cosas. Nadie lo documenta, nadie lo asigna, pero ya sabes lo que va a pasar. Lo oyes flotar.

Un día (viernes a última hora, seguro) alguien abre un ticket con prioridad alta y asunto ambiguo: “Problema con SQL”. Ni reproducible, ni claro. Y para cuando llega a ti, ya eres el responsable. Del ERP. Del rendimiento. De todo.

Este marrón huele a cursores usados alegremente por algún genio que ha leído un blog equivocado. Y te va a tocar explicarlo. Otra vez.

El marrón fulminante: el «¿qué ha pasado?» a las 8:00

Son las 7:58. Te conectas. Parece que todo está tranquilo. Hasta que alguien grita por Teams: “¡la base de datos está caída!”

Miras los logs. Alguien reinició el servicio de SQL Server durante la noche. ¿Motivo? “Estaba lento y pensé que eso lo arreglaría, luego el servicio no se paraba y reinicié el servidor”.

No sabemos qué ha pasado, solo tenemos aplicaciones paradas y usuarios locos por los pasillos.

Y tú, desayunando con una base de datos de 25 Tb en recuperación.

Este es el marrón que se instala sin pedir permiso. Lo único que puedes hacer es ponerte los guantes de forense, y rezar para que pase cuanto antes.

El automarrón: lo hiciste tú, y lo sabes

Hay veces que el marrón no viene de fuera. Te lo cocinas tú solito.

Aceptaste esa migración “sencilla” de SQL Server 2012 a 2022. Te dijeron que solo había que mover “un par de bases”. Ahora estás descubriendo jobs con código T-SQL del pleistoceno, linked servers a dominios que ya no existen, y stored procedures que funcionan por magia negra.

Y todo tiene que estar listo este fin de semana. Por supuesto.

Es el automarrón. Y el problema no es el marrón. Es tu optimismo que te llevó a no mirar dos veces.

El marrón pata negra: ese proyecto que recordarás siempre

Hay marrones, y luego está ese proyecto que te cambió la vida. El que te hizo cuestionarte tus decisiones vitales.

Un data warehouse mal diseñado que hay que “reoptimizar”. Con cientos de tablas de millones de registros sin índices, y vistas anidadas que ya tienen su propio ecosistema. Con consultas que tardan horas y desarrolladores que te juran que “antes iba rápido”.

Es el marrón pata negra. No se arregla. Se sobrevive. Y si logras salir de ahí, probablemente acabarás con un tic nervioso… y un máster en tuning sin quererlo.

El marrón de última hora: el clásico de viernes tarde

Viernes, 14:59. Recoges. Cierra sesión. Y entonces… “oye, una cosilla antes de que te vayas”.

Spoiler: no es una cosilla.

Es un cambio en producción. Un script que nadie ha revisado. Un MERGE que te juran que va bien “porque lo hemos probado en dev”. Unos índices que hay que “crear rapidito” porque el CTO ha leído en LinkedIn que eso mejora el rendimiento.

Y tú, con el abrigo puesto, ejecutando con miedo un script que viene de un Excel. Bienvenido al marrón invocado. No saldrás antes de las 21:00. Si sales.

El marrón mutante: el que cambia cada día

Te asignan un problema de rendimiento. Miras. Optimización sencilla. Pones un índice. Va mejor.

Pero luego cambia el plan de ejecución. Luego te enteras de que han cambiado el MAXDOP sin avisarte. Luego la tabla crece un 300% de un día para otro. Y el problema vuelve. Peor.

El marrón mutante nunca termina. Hoy es CPU, mañana IO, pasado bloqueos. Intentas aplicar parches, pero no hay final. Es como dar soporte a una base que se autodestruye a diario y se recompone… peor.

Vives en un entorno hostil.

El marrón sonda: el disfrazado de consulta inocente

“Una duda rápida sobre un procedimiento que tarda un poco…”

Error. Ya estás dentro.

Empieza como una duda. Luego te piden revisar el plan. Luego optimizar. Luego reescribir. Luego hacer un informe. Luego… estás haciendo tú todo.

Los marrones sonda son los peores porque son invisibles. Te atrapan por empatía. No porque puedas decir que no, sino porque ya estás en medio. Y claro, ya que estás…

El pressing brown: presión en estéreo

Cliente cabreado. Jefe nervioso. Equipo de desarrollo esperando. Todos preguntan. Todos presionan.

Y tú, el DBA, recibiendo por todos lados. Con logs, sin contexto, y con el “esto no puede estar fallando, si no hemos tocado nada” como único diagnóstico.

Es el pressing brown. Nadie lo admite, pero todos lo han hecho: tirar el marrón al de bases porque “seguro que es algo del SQL”.

Y a ti te toca arreglarlo. Sin información. Sin culpa. Sin gloria.

El brown shower: todo cae a la vez

Backup corrupto. Alerta de disco. AG desincronizada. Login bloqueado. Limpieza de datos que ha borrado datos de más (a quien se le ocurre poner las FK con borrado en cascada…). El entorno ha dicho basta. Y todo a la vez.

Eso no es un marrón. Es un brown shower.

Cuando pasa, no arreglas. Contienes. Priorizas, sobrevives, y rezas porque el clúster no decida reiniciarse. Y si alguien pregunta cómo va todo, solo di: “controlado”, mientras lloras por dentro.

Conclusión: el terror real se ejecuta en SQL

Que sí, que Halloween da miedo. Pero no tanto como ejecutar un DELETE sin WHERE en la base de producción, o que el backup del FULL no incluya las bases más críticas.

Nosotros no necesitamos sustos. Ya los trae el trabajo.

Y recuerda: si un jefe te dice “es una tarea rápida”, asegúrate de tener a mano tu última copia del CV actualizado. Y una linterna. Porque se viene noche larga.

Feliz Halloween, compañeros de marrones. Que los browners pasen de largo… o al menos os pillen con un buen plan de contingencia.

Oct

2025

OPTIMIZED SP_EXECUTESQL: Novedad de SQL Server 2025

Con la llegada de SQL Server 2025, Microsoft introducirá una serie de mejoras orientadas a optimizar el rendimiento del motor. Una de ellas es la nueva configuración OPTIMIZED_SP_EXECUTESQL, pensada específicamente para entornos que hacen uso intensivo de SQL dinámico a través de sp_executesql. En este artículo profundizo en su funcionamiento, cómo activarla, qué impacto tiene en la caché de planes y cómo se comporta bajo carga concurrente.

Contexto: el problema con sp_executesql y el plan cache

Cuando ejecutamos consultas dinámicas con sp_executesql, especialmente en entornos con alta concurrencia, SQL Server puede compilar múltiples planes para lo que, conceptualmente, es la misma consulta. Aunque el texto del lote (batch text) sea idéntico y se usen parámetros, el compilador no siempre consigue identificarlo como la misma ejecución, lo que termina generando entradas repetidas en la plan cache.

Esto da lugar a varios problemas conocidos:

Bloat en la plan cache, con decenas o cientos de planes similares almacenados.
Consumo innecesario de CPU por compilaciones redundantes.
Contención en la compilación, cuando múltiples sesiones intentan compilar la misma consulta al mismo tiempo.

Con OPTIMIZED_SP_EXECUTESQL, SQL Server introduce un nuevo mecanismo para mitigar estos efectos.

¿Qué es OPTIMIZED SP_EXECUTESQL?

Se trata de una configuración a nivel de base de datos que se encuentra desactivada por defecto y que puede activarse mediante ALTER DATABASE SCOPED CONFIGURATION. Su objetivo principal es optimizar la forma en que SQL Server gestiona la compilación y almacenamiento en caché de planes asociados a ejecuciones de sp_executesql.

Cuando se activa esta opción, el comportamiento cambia significativamente:

La primera ejecución de un lote dinámico mediante sp_executesql compila el plan normalmente.
Otras sesiones concurrentes que ejecutan el mismo lote esperan a que finalice la compilación.
Una vez compilado, todas las sesiones reutilizan el mismo plan, del mismo modo que lo harían si fuera un procedimiento almacenado.

Requisitos y dependencias

Lo primero, obviamente, es tener SQL Server 2025 y tu base de datos en un nivel de compatibilidad 170. Además, si en tu base de datos tienes activada la opción de actualización automática de estadísticas, Microsoft recomienda habilitar también ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY (más bien es un requisito pero, ¿has visto qué bien me ha quedado lo de “Microsoft recomienda”?). Esto asegura que el nuevo comportamiento no introduzca contención innecesaria durante las actualizaciones estadísticas, en escenarios de alta concurrencia.

Cómo activarlo

Para habilitar la funcionalidad, puedes ejecutar el siguiente bloque:

USE [TuBaseDeDatos];
GO
ALTER DATABASE SCOPED CONFIGURATION SET ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY = ON;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_SP_EXECUTESQL =ON;
GO

Recuerda, necesitas estar en nivel de compatibilidad 170 (SQL Server 2025) para que la opción sea válida.

Puedes comprobar el estado actual de la configuración con:

SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE name IN ('OPTIMIZED_SP_EXECUTESQL', 'ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY');

Demostración práctica

Vamos a ejecutar una serie de pruebas en una base de datos StackOverflow (modo de compatibilidad 170) para observar el impacto real de esta configuración en la plan cache.

Paso 1: Asegurar que la opción está desactivada

USE StackOverflow2010;
GO
ALTER DATABASE SCOPED CONFIGURATION SET ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY = OFF;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_SP_EXECUTESQL = OFF;
GO

Paso 2: Limpiar la caché de planes

DBCC FREEPROCCACHE;
GO

Paso 3: Ejecutar carga concurrente

Usaremos SQLQueryStress para lanzar la siguiente consulta, que ejecuta sp_executesql de forma concurrente:

DECLARE @sql NVARCHAR(MAX) = N'SELECT COUNT(*) FROM dbo.Posts WHERE PostTypeId = @PostTypeId AND Score > @Score';

DECLARE @params NVARCHAR(MAX) = N'@PostTypeId INT, @Score INT';

EXEC sys.sp_executesql @sql, @params, @PostTypeId = 1, @Score = 2000;

Parámetros en SQLQueryStress:

Iteraciones por hilo: 10
Número de hilos: 100

Esto generará 1000 ejecuciones concurrentes de la misma consulta dinámica.

Paso 4: Analizar la plan cache

Una vez completadas las ejecuciones, inspeccionamos el número de planes generados:

SELECT 
    qs.plan_handle,
    qs.sql_handle,
    qs.creation_time,
    qs.execution_count,
    st.text AS sql_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE st.text LIKE '%SELECT COUNT(*) FROM dbo.Posts%'
ORDER BY qs.creation_time DESC;

Resultado esperado (sin optimización): múltiples planes distintos (en pruebas reales, se observan entre 20 y 30 para este escenario), aunque la consulta sea la misma.

Esto evidencia el comportamiento ineficiente por defecto: múltiples planes para la misma carga.

Paso 5: Activar la optimización

USE StackOverflow;
GO
ALTER DATABASE SCOPED CONFIGURATION SET ASYNC_STATS_UPDATE_WAIT_AT_LOW_PRIORITY = ON;
GO
ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZED_SP_EXECUTESQL = ON;
GO

Paso 6: Limpiar de nuevo la caché

DBCC FREEPROCCACHE;
GO

Paso 7: Ejecutar la misma carga

Volvemos a lanzar los 100 hilos concurrentes con SQLQueryStress, exactamente como antes.

Paso 8: Analizar resultados

Ejecutamos de nuevo la consulta sobre la plan cache:

SELECT 
    qs.plan_handle,
    qs.sql_handle,
    qs.creation_time,
    qs.execution_count,
    st.text AS sql_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE st.text LIKE '%SELECT COUNT(*) FROM dbo.Posts%'
ORDER BY qs.creation_time DESC;

Resultado esperado (con optimización): una sola entrada en la caché de planes, con una execution_count acumulada de 1000. El compilador ha tratado la consulta dinámica como si fuese un procedimiento almacenado.

Este comportamiento elimina de raíz el bloat en la caché y evita la compilación paralela.

¿Qué hace SQL Server exactamente?

El mecanismo detrás de esta optimización replica el modelo clásico de los procedimientos almacenados:

La primera ejecución de una consulta concreta compila el plan.
El resto de ejecuciones esperan a que ese plan esté disponible.
Una vez compilado, todas las ejecuciones reutilizan ese mismo plan.

Este comportamiento garantiza una mayor eficiencia tanto en uso de CPU como en gestión de memoria. Ya no veremos un plan por cada sesión, sino un único plan compartido y referenciado por todas.

Consideraciones finales

Este cambio solo aplica a sp_executesql. No afecta a EXEC() ni a otros mecanismos de ejecución dinámica.

Las consultas deben ser realmente idénticas (texto y parámetros) para que se detecte la coincidencia.

Si tu aplicación genera SQL dinámico con pequeñas variaciones en los literales o estructura, el beneficio será menor.

La mejora se aprecia especialmente en entornos con alta concurrencia o patrones repetitivos.

Conclusión

OPTIMIZED_SP_EXECUTESQL es una de las mejoras más importantes en la gestión del plan cache que hemos visto en años. Su activación puede suponer una diferencia notable en servidores que sufrían problemas de rendimiento por exceso de compilaciones o saturación de memoria con planes efímeros.

Es una de esas configuraciones que, bien aplicada, no solo mejora el rendimiento, sino que permite aprovechar mejor los recursos existentes. No es una solución mágica, pero sí una herramienta eficaz para un problema conocido.

Si trabajas con aplicaciones que generan SQL dinámico intensivo y tienes pensado actualizar SQL Server 2025 cuando sea estable, este cambio debería estar en tu lista de tareas prioritarias.

Oct

2025

Sinónimos en SQL Server. SQL Basics

No todos los objetos de SQL Server nacieron para ser usados con confianza ciega. Algunos tienen nombre de perfume barato y generan sensaciones parecidas. Hoy hablamos de los sinónimos, esos alias de objetos que pueden facilitarte la vida o clavarte una estaca en mitad de una migración mal hecha.

Los sinónimos (synonyms, si estás leyendo esto con el Management Studio en inglés) son una característica de SQL Server que permite crear un nombre alternativo para referenciar a un objeto, ya sea una tabla, vista, procedimiento almacenado o función. A primera vista suena bien. Evitas tener que escribir nombres de servidores, bases de datos y esquemas cada vez que llamas a algo remoto. Pero como todo en la vida, cuando lo haces demasiado fácil, el problema aparece justo después.

¿Qué es un sinónimo?

Los sinónimos permiten definir un alias a un objeto que puede estar incluso en otro servidor. Esto puede incluir tablas en bases de datos remotas, procedimientos almacenados en otras instancias, funciones en otro universo, etc.

Por ejemplo, puedes tener un sinónimo así:

CREATE SYNONYM ProductoExt 
FOR [ServidorRemoto].[BaseDatosRemota].[dbo].[Producto];

Y desde ese momento puedes hacer:

SELECT * FROM ProductoExt;

Sin preocuparte de toda la parafernalia de nombres largos y cuatro partes. Es cómodo, sí. Pero también estás metiendo debajo de la alfombra varias capas de dependencia, latencia y seguridad implícita.

¿Por qué usar sinónimos?

Vale, vamos a concederle al sinónimo su minuto de gloria. Hay casos en los que puede tener sentido.

Cuando trabajas con entornos donde los nombres de base de datos o incluso los servidores cambian con frecuencia (hola, entornos de desarrollo y preproducción mal organizados), usar sinónimos permite centralizar esos nombres en un solo punto. En lugar de cambiar 58 procedimientos almacenados, cambias un solo sinónimo. Bravo.

También son útiles cuando accedes a objetos remotos y no quieres estar repitiendo la ruta de cuatro partes cada vez. Si el enlace funciona y las credenciales no han caducado, puede parecer magia.

Y por supuesto, si estás trabajando con múltiples bases de datos y necesitas mantener cierto nivel de encapsulamiento o abstracción (palabra que aquí significa “hacer como que lo que depende de otro servidor no depende de él”), un sinónimo puede ayudarte.

Pero no te emociones.

Los problemas empiezan con la transparencia

El gran problema de los sinónimos es que precisamente no parece que estás accediendo a algo remoto.

Tú haces un SELECT * FROM ProductoExt y ni idea de que en realidad estás yendo a otro servidor, otra base de datos, o peor aún, a un servidor vinculado (linked server) que va a dar más vueltas que un sp_executesql dentro de un cursor.

Esa falta de visibilidad genera problemas muy reales:

Latencia inesperada. Estás accediendo a una tabla en otro continente y no lo sabías.
Errores de seguridad. ¿Quién tiene permiso en el objeto real? ¿Qué cuenta usa el servidor vinculado? ¿Tienes doble salto Kerberos bien configurado?
Fragmentación lógica. El código parece limpio, pero la traza de dependencias es un infierno.

Y como cereza del pastel: cuando algo falla, el mensaje de error puede ser tan claro como una excepción de .NET lanzada por un junior con prisa.

Rendimiento de los sinónimos

Vamos a dejar esto claro, usar sinónimos no introduce penalización de rendimiento por sí mismo. No hay sobrecarga, ni resolución dinámica, ni instrucciones mágicas de más. Un sinónimo es un alias, y el plan de ejecución generado es exactamente el mismo que si hubieras usado el nombre completo del objeto original.

Entonces, ¿dónde está el problema?

En que el sinónimo oculta la naturaleza del objeto que estás tocando. Puedes estar accediendo a una tabla local… o a una tabla en otro servidor a través de un Linked Server. Y como el nombre del sinónimo no da pistas, el riesgo es que estés haciendo una SELECT * a 10 millones de registros en remoto sin saberlo.

Esa opacidad puede llevar a errores de diseño y análisis, planificas como si accedieras a una tabla local, pero detrás hay un OLEDB pasando datos entre servidores. Y eso sí que es un problema de rendimiento, de los serios.

Además, al estar encapsulado como alias, el sinónimo puede dificultar el análisis del plan de ejecución, sobre todo cuando hay muchos niveles de indirección. No porque el plan sea distinto, sino porque hay que tirar del hilo hasta encontrar el objeto real.

Y no, los sinónimos no hacen caché de nada. Ni de la resolución del nombre, ni del esquema, ni del servidor remoto. Cada vez que los usas, se resuelve el nombre desde cero. Esto normalmente no es un cuello de botella, pero en entornos de alta concurrencia o con muchas referencias cruzadas, puede notarse. Poco, pero lo justo para volverse molesto.

Así que el sinónimo no penaliza, pero tampoco te avisa. Por eso conviene saber muy bien qué estás llamando, de dónde cuelga, y si realmente necesitas ese acceso encapsulado. Porque cuando el rendimiento se resiente, el sinónimo suele ser el último sitio donde alguien mira… y a veces es justo donde empezó el desastre.

¿Y la seguridad? ¿Qué podría salir mal?

En realidad, poco. O al menos, nada distinto a lo que ya puede salir mal sin sinónimos.

Porque, que quede claro por si no lo he dicho suficiente: un sinónimo es solo un alias. No altera cómo funciona la seguridad en SQL Server. Los permisos que necesita un usuario para acceder a un sinónimo son exactamente los mismos que si accediera directamente al objeto original con su nombre completo.

Si no tienes permisos sobre la tabla, vista o procedimiento al que apunta el sinónimo, obtendrás el mismo error que si usaras [Base].[Esquema].[Objeto] a pelo. Y si los tienes, funcionará. Punto.

Lo mismo aplica si el objeto está en otra base de datos: el login debe tener un usuario definido en esa base, con permisos suficientes. Y si el sinónimo apunta a un Linked Server, el control lo marca la configuración del servidor vinculado. Pero eso pasaría exactamente igual si accedieras con nombres de cuatro partes. No hay atajo, ni puerta trasera, ni cambio de contexto.

Lo único que realmente puede salir mal (y lo hace más de lo que parece) es que el objeto original cambie o desaparezca. El sinónimo no se entera de nada. Si el objeto cambia de esquema, se renombra o se elimina, el sinónimo sigue ahí, inerte, esperando a que alguien lo use… y falle. Porque SQL Server no valida los sinónimos en tiempo de creación, ni en tiempo de despliegue. Solo en tiempo de ejecución.

¿Qué objetos pueden tener sinónimos?

Los sinónimos en SQL Server no son tan versátiles como a veces se cree. No puedes crear alias para “lo que te dé la gana”. Están limitados a objetos individuales y concretos. Vamos a dejar esto bien claro para evitar que alguien pierda una hora pegándose con errores de sintaxis absurdos.

Sí puedes crear sinónimos sobre:

Tablas (locales o remotas, si usas nombres de cuatro partes correctamente).
Vistas.
Procedimientos almacenados.
Funciones definidas por el usuario (escalares o con valores de tabla).

Siempre que el objeto esté definido en un esquema, sea accedible por nombre completo y tenga una representación clara en la metadata, puedes hacerle un sinónimo.

No puedes crear sinónimos sobre:

Tablas temporales (#Local, ##Global).
Triggers. (No me preguntéis por qué alguien lo intentaría).
Constraints (CHECK, DEFAULT, FOREIGN KEY, etc.).
Columnas. Lo de SELECT columna AS alias es otra cosa.
Tipos definidos por el usuario (UDT), reglas (RULE), secuencias (SEQUENCE), ni defaults independientes.
Funciones del sistema (GETDATE(), ISNULL(), etc.).
Objetos CLR o ensamblados .NET.
Índices, particiones, estadísticas o cualquier cosa que no sea “llamable” desde T-SQL por sí sola.
Bases de datos. No puedes hacer un alias de una base de datos entera. Olvídalo.
Esquemas. Tampoco puedes crear un sinónimo para un esquema. Ni para [dbo], ni para ninguno. Si necesitas encapsular el acceso a todos los objetos de un esquema remoto, necesitarás crear un sinónimo por cada objeto. O usar otro enfoque (vistas, procedimientos, sin llorar).

Recuerda: los sinónimos apuntan a objetos, no a contenedores de objetos. Si te estás planteando crear sinónimos para simplificar nombres de base de datos o de esquema, estás intentando que hagan algo para lo que no fueron diseñados. Te toca o escribir más código o usar una capa de abstracción de verdad.

¿Versionado y mantenimiento?

Cuando usas sinónimos para abstraer el acceso a objetos en otras bases de datos, estás añadiendo una capa más que también necesita mantenimiento. Y como suele pasar, se te va a olvidar.

¿Haces despliegues con DACPACs? ¿Tienes control de versiones? ¿Sabes en qué base de datos está realmente cada sinónimo? ¿Cuándo fue la última vez que hiciste un DROP SYNONYM?

Exacto.

Además, los sinónimos no aparecen claramente en muchas herramientas de análisis de dependencias. Ni en algunos generadores de documentación. Son casi como variables globales: parecen útiles hasta que tu entorno tiene más de dos personas y cinco entornos.

¿Y cómo los controlo?

Si has heredado una base de datos con decenas (o cientos) de sinónimos, lo primero es hacer inventario:

SELECT name, base_object_name
FROM sys.synonyms;

Con eso ya puedes empezar a trazar qué objetos están apuntando a qué lugares. Usa sys.sql_expression_dependencies para ver si están en uso, aunque no siempre captura todo.

Haz pruebas. Valida que cada sinónimo realmente apunte a algo válido. Y luego decide si vale la pena mantenerlo o rediseñar esa parte del acceso.

No olvides que puedes hacer scripts automáticos para regenerarlos si decides mover entornos. Pero asegúrate de que esos scripts están bajo control de versiones, como Dios y el sentido común mandan.

Conclusión

Los sinónimos son ese tipo de herramienta que SQL Server te da con una sonrisa pero sin instrucciones. Te ahorran escritura, sí, pero a cambio te introducen opacidad, dependencias ocultas y posibles dolores de cabeza cuando algo deja de funcionar y nadie recuerda de dónde venía ese nombre tan bonito.

No están prohibidos. Pero tampoco deberían ser tu primera opción. Úsalos con mesura, con documentación, y con una pizca de paranoia técnica. Porque el día que falle un sinónimo en producción, nadie va a buscar el problema en ese alias inofensivo… hasta que ya es demasiado tarde.

cloud

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes