Otros

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
06
Ene
2026
Área 404: cuando dos informáticos se sientan a rajar

Área 404: cuando dos informáticos se sientan a rajar

Esto no es un artículo técnico. Esta vez no vamos a hablar de índices, ni de wait stats, ni de cómo Access sigue arrastrando pies por la empresa como un zombi bien vestido. Hoy vengo a contaros algo diferente. Algo que, si habéis disfrutado alguna vez de una conversación técnica con colegas en el bar, probablemente os interese.

He arrancado un podcast junto a Juanjo Luna. Sí, ese Juanjo Luna: MVP, experto en Access, instructor en LinkedIn, y propietario de una de las bibliotecas de gadgets más absurdamente variadas que he visto. Le das una camara y un micro y te monta un estudio. Y en vez de limitarlo a charlas de pasillo o eventos, lo hemos convertido en un proyecto con nombre propio: Área 404.

¿Y esto de qué va?

De tecnología. Pero no de la que huele a keynote ni de la que viene envuelta en storytelling de marketing. Hablamos de la que usamos cada día, la que falla justo cuando no debe, la que heredamos con dolor… y también de la que nos hace disfrutar. Cables, cámaras, bases de datos, gadgets, interfaces absurdos y decisiones arquitectónicas que sólo se entienden si has pasado por ellas.

No es un podcast de SQL Server. Tampoco es un podcast de Access. Es un podcast de tecnología hecha y sufrida por quienes la usamos. No hay guion. No hay producto que vender. Solo dos voces con criterio (a veces) y experiencia (buena o mala), hablando como se habla en las cervezas al terminar un evento técnico: con confianza, con ironía y con ganas de contar lo que no se suele contar.

Área 404: el podcast sin posturitas

El nombre no es casual. Área 404 es ese sitio donde van las charlas que no tienen cabida en los eventos. Donde hablamos de lo que pasa de verdad, cuando las cámaras no graban y el ordenador ya está apagado. Y sí, también es el sitio donde nos reímos de nuestras propias desgracias tecnológicas. Porque si no te has reído nunca de un SELECT * en producción, es que aún no has vivido lo suficiente como DBA.

Queremos que el podcast sea eso: una conversación honesta entre profesionales. Sin postureo, sin agendas ocultas, sin «te traigo a este invitado porque patrocina el evento». Aquí no se vende nada. Aquí se habla. Y si se nos va la pinza con una Raspberry o con un script de PowerShell maldito, pues se nos va. Pero se entiende. Y se agradece.

Episodio piloto: Access no está muerto. Solo se hace el dormido.

El primer episodio ya está disponible. Empezamos fuerte, con esa eterna pregunta que lleva dos décadas dando vueltas por los pasillos: ¿Está Microsoft Access realmente muerto?

Spoiler: no. Y sí. Depende de a quién le preguntes y de en qué empresa trabajes.

En este piloto repasamos por qué Access sigue ahí, cuándo tiene sentido usarlo (sí, a veces lo tiene), cómo puede convivir con SQL Server, y qué pasa cuando heredas una de esas bases «que ya se migrarán». Todo con cerveza técnica en mano, sin filtros y con la experiencia de alguien que ha visto más Access en producción que muchos jefes de proyecto.

Suscríbete. O no, pero no digas que no te lo advertí.

Ya está en YouTube. Ya puedes escucharlo. Si quieres ver a dos MVPs discutiendo sin PowerPoints y con argumentos, ahí lo tienes. Si alguna vez has vivido una migración imposible, si alguna vez te has preguntado por qué demonios el micro que compraste no se oye bien en Teams, si te fascinan los gadgets innecesarios pero imprescindibles… entonces este podcast es para ti.

Y si no te interesa nada de esto, también está bien. Pero luego no vengas diciendo que nadie hace contenido técnico con gracia.

Nos vemos en Área 404. O nos escuchamos. O nos sufrimos. Todo vale.

Publicado por Roberto Carrancio en Otros, 0 comentarios
31
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:

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

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.

Publicado por Roberto Carrancio en Otros, 0 comentarios
13
Oct
2025

Final de año de comunidad: eventos, charlas y oportunidades

Se acerca el final del año y, como suele pasar, nos entra la prisa por encajar en el calendario todo lo que no hicimos en primavera. Resultado, el último trimestre está cargado de eventos, meetups, conferencias y saraos varios. Y no me quejo, al contrario. Es ahora cuando se ve quién está realmente comprometido con la comunidad técnica y quién solo se apunta cuando hay camisetas gratis.

Este artículo no va de SQL Server (aunque aparecerá, no os preocupéis). Va de comunidad. De compartir conocimiento, de subirse al escenario a contar lo que uno ha aprendido a base de picar piedra. Y, sobre todo, va de animar a más gente a participar. Así que si eres de los que siempre dicen “me gustaría dar una charla algún día” o simplemente nunca antes te has animado a venir de público a un evento… este trimestre tienes varios “algún día” a tiro.

Vamos al lío. Os dejo el calendario de eventos clave para lo que queda de año, algunos de los cuales tengo el placer de participar directamente.

Power BI & Fabric Days (Barcelona, 17 y 18 de octubre)

Este viernes y sábado se celebra en Barcelona una de las citas clave para los que trabajamos con tecnologías de datos de Microsoft.

En mi caso, estaré dando una charla sobre Power BI Report Server (PBIRS), ese gran olvidado que sigue teniendo hueco (y sentido) en muchos entornos corporativos. Pero no vengo solo, hay un montón de sesiones, talleres prácticos y espacio para hacer networking del bueno. Ya sabes ese networking que empieza con “¿y tú qué haces en tu curro?” y acaba en “te paso el script que usamos para eso”.

Eventos BCN talleres
Eventos BCN Charlas

El evento es gratuito, con registro previo y plazas limitadas. Si estás en Barcelona o puedes desplazarte, no hay excusa. Consigue aquí tu entrada para los talleres o para las charlas.

Optimización de SQL para Power Platform (Online, 30 de octubre)

El jueves 30 de octubre tengo sesión online para la comunidad de Power Platform Madrid. Vamos a hablar de SQL, claro, pero desde la óptica que cada vez más nos piden: ¿cómo optimizar lo que hay detrás de nuestros reportes en Power BI y Fabric?

Spoiler: Muchas veces, lo que falla no está en la nube, sino en ese SELECT * que alguien pensó que era inocente.

Eventos Online PPM

Será una sesión práctica, sin más PowerPoints del imprescindible, pensada para quienes están sufriendo con conectores lentos, tablas compartidas con medio planeta y consultas que tardan más que una reunión de status. Regístrate aquí para no perdértelo.

NetCoreConf Madrid (14 de noviembre)

Evento veterano donde los haya, NetCoreConf vuelve a Madrid con una edición presencial que promete. Aunque el call for speakers aún está abierto, ya se sabe que este evento es terreno fértil para desarrolladores de nivel, sesiones técnicas de verdad y, cómo no, muchas charlas sobre datos, arquitectura y rendimiento.

Yo pienso estar allí, veremos si como ponente o no. Porque aunque vayas solo de oyente, siempre se aprende algo. O al menos descubres cómo están resolviendo otros lo que tú estás parcheando como puedes.

Si estás pensando enviar sesión, aún llegas. Y si no, al menos resérvate el día en el calendario.

Data Saturday Madrid (27 al 29 de noviembre)

Este es el evento. Así, sin más.

Data Saturday Madrid es la cita principal de la comunidad de datos en España. Y este año viene con tres días completos: dos días de talleres intensivos y un día de conferencias con ponentes de primera línea, tanto nacionales como internacionales.

La agenda aún no está publicada (a fecha de escribir esto), pero no hace falta verla para saber que el nivel será alto. Si vienes, tráete libreta y preguntas. Y si no vienes… bueno, luego no digas que no te enteras de las tendencias del sector.

Estaré por allí seguro. Y si te cruzas conmigo, saluda. Siempre es buen momento para desvirtualizar a gente que lleva años sufriendo los mismos deadlocks que tú.

Corre y consigue aquí tu entrada antes de que se acaben (el año pasado mucha gente se quedó fuera por Sold Out)

Non-Profit Community Day Spain (Madrid, 4 de diciembre)

Este es un evento distinto, y eso es lo que lo hace especial. El Non-Profit Community Day Spain se celebra en las oficinas de Microsoft en Madrid y está centrado en ONGs, fundaciones y proyectos sin ánimo de lucro.

Habrá charlas técnicas, casos de uso reales y mucho foco en cómo la tecnología puede aportar valor social. No hay agenda todavía cerrada porque el Call for Speakers sigue abierto, pero si tienes una historia que contar (y todos tenemos alguna), aquí tienes un escenario ideal.

Tecnología con propósito. Y en un entorno que suele estar infrarrepresentado en nuestros circuitos habituales.

Christmas Power Platform (12 y 13 de diciembre, online)

Seguimos con las causas solidarias. 

La segunda edición de este evento benéfico tiene todos los ingredientes que deberían movernos a participar: es online, es para una buena causa (recaudación para una ONG que trabaja con niños hospitalizados) y está abierto a todos.

Las charlas son de 20 minutos, formato ligero, y cubren cualquier tema relacionado con datos, Power Platform, IA, automatización o BI. Si alguna vez has dicho “yo no tengo nivel para hablar en público”, este es el sitio perfecto para empezar. Nadie te va a juzgar, y todos vamos a aprender algo. Animate y presenta tu sesión aquí.

Y si no te animas a presentar sesión, al menos conéctate y aporta con tu presencia, con una donación o simplemente dando difusión. A veces, ser comunidad también es esto, estar cuando no hay regalos ni sorteos, pero sí mucho corazón.

Comunidad SQL Server Español (14/10 y cada segundo martes del mes)

No podía cerrar esta agenda sin mencionar los eventos online de la comunidad SQL Server Español, que organizo junto a Cristina y que cada mes reúnen a decenas de profesionales con algo en común: siguen trabajando con SQL Server y quieren hacerlo mejor.

Este martes 14 de octubre (sí, mañana si estás leyendo esto el lunes), contaremos con Jorge Perona, que nos hablará de cómo administrar entornos on-prem desde la nube usando Azure Arc. Una charla muy oportuna, especialmente para quienes andan en entornos híbridos donde lo único constante es el caos de licencias, políticas y versiones mezcladas. Consigue tu entrada totalmente gratis aquí.

Y como cada mes, nos volveremos a ver el segundo martes de noviembre y el segundo martes de diciembre. Aún no puedo adelantaros las ponencias que serán, pero como siempre, serán sesiones técnicas de verdad. Nada de postureo. Aquí venimos a hablar de índices, de rendimiento, de administración real.

Si trabajas con SQL Server, hablas español y aún no te has pasado por uno de estos eventos, no sé a qué esperas.

Conclusión

El calendario está lleno. Hay eventos en todas las modalidades: presenciales, online, técnicos, sociales, de comunidad pura y de divulgación. No todos te interesarán, y no pasa nada. Pero si te interesa mejorar como profesional, hacer contactos más allá de LinkedIn y aprender de gente que ya ha pasado por lo mismo que tú… no hay mejor inversión de tiempo.

Además, si llevas tiempo pensando en dar una charla, enviar un paper o simplemente aparecer por un evento y escuchar, este último tramo del año es tu oportunidad. Entre sesiones mensuales, eventos solidarios y conferencias de alto nivel, el menú no puede ser más completo.

Y ya sabes: quien no se mueve, no sale en la foto. Nos vemos en los eventos.

PD: Si quieres hacerte con uno de mis libros o ya lo tienes y quieres una dedicatoria vente a uno de estos eventos y avísame.

Publicado por Roberto Carrancio en Otros, 0 comentarios
06
Oct
2025

Guía para reclutar perfiles SQL sin morir en el intento. Manual para RRHH

¿Alguna vez has tenido que cubrir un puesto relacionado con bases de datos SQL y has sentido que el perfil parecía más un conjuro que una oferta de empleo? Tranquilo, no estás solo. Lo de “buscamos un DBA que también sepa de Power BI, Python, backups, modelado de datos, administración de Azure, tuning de consultas, y que además tenga skills de comunicación” no es una exageración. Es literalmente lo que me he encontrado más de una vez. Y no, no es viable.

Este artículo no es para criticar (bueno, solo un poco), sino para ayudar. Está dirigido a profesionales de selección de personal que, sin ser técnicos, tienen que enfrentarse al reto de reclutar a alguien que sí lo es. Alguien que, además, trabaja con eso tan abstracto y escurridizo que es “el mundo SQL”.

Vamos a dejar claras las diferencias entre los principales perfiles de datos que tocan SQL, porque no todos hacen lo mismo, y desde luego no se les puede tratar como si fueran intercambiables. También repasaremos un glosario básico de términos que no hacen falta dominar, pero sí reconocer para no quedar en evidencia durante una entrevista.

Todos tocan SQL, pero no son lo mismo

Lo primero que hay que entender es que “saber SQL” no define un perfil. Es como decir que alguien que sabe escribir puede ser novelista, abogado, periodista o copywriter. Todos escriben, pero no tienen el mismo rol ni se enfrentan a los mismos problemas.

El DBA (Database Administrator)

El DBA es el responsable de que la base de datos funcione. Y no me refiero solo a que “funcione”, sino a que sea segura, estable, rápida y que no explote cuando más falta hace. Hay varios tipos de DBAs: los hay de infraestructura (montan y configuran el servidor, las instancias, se pelean con el almacenamiento), de rendimiento (se dedican a afinar consultas, crear índices, revisar planes de ejecución), y también los que cubren todo y sobreviven a base de café y alerts.

No confundas un DBA de SQL Server con uno de Oracle, ni con uno de PostgreSQL. No, no son equivalentes. Los conceptos se parecen, pero los comandos, herramientas, modos de operar y hasta las buenas prácticas cambian.

El desarrollador SQL o de BI

Este perfil sí escribe SQL todos los días, pero con un objetivo muy distinto al del DBA. Se dedica a generar consultas, crear procedimientos almacenados, hacer informes, alimentar modelos de datos o integrar fuentes externas. Suele moverse en entornos de reporting, ETL o modelado. Si sabe hacer backups, probablemente es porque un día le tocó hacerlo a él y no había nadie más.

El analista de datos

Aquí la confusión es habitual. El analista suele consumir datos, no gestionarlos. Sabe lanzar consultas (normalmente sencillas), trabajar con herramientas de visualización como Power BI o Tableau, y generar conclusiones. No se le puede pedir que optimice un índice ni que diseñe un modelo físico de base de datos. Es otro rol.

El ingeniero de datos

Este perfil está más cerca de la infraestructura moderna, los pipelines, la automatización y las arquitecturas distribuidas. Sabe de SQL, pero también de Spark, Azure Data Factory, Synapse, Databricks y similares. Le puedes hablar de particionamiento, de lag en streaming y de integración con data lakes, pero probablemente no sabe mucho de tuning en SQL Server.

Y sí, la tecnología importa

Cada sistema gestor tiene sus peculiaridades. Un experto en MySQL no puede entrar mañana a administrar SQL Server sin un mínimo periodo de adaptación. Ni los comandos son los mismos, ni las herramientas de administración, ni el enfoque. Que todos hablen SQL no significa que hagan lo mismo.

Errores frecuentes al redactar una oferta de trabajo técnica con SQL

Si has cometido alguno de estos, no te preocupes. A todos nos ha pasado. Pero aquí van unas cuantas cosas que conviene evitar:

  1. Mezclar perfiles incompatibles. Pedir un “DBA que también haga ETLs y reporting” es como buscar un fontanero que repare calderas y además pinte retratos al óleo. Existen, pero no son baratos, y no es razonable esperarlo por defecto.
  2. Lista de tecnologías sin criterio. SSIS, Airflow, Glue, Informatica, Talend… todos en el mismo párrafo. Sin contexto. Como si fueran toppings de pizza. A veces da la sensación de que la lista la ha hecho alguien buscando palabras clave en LinkedIn.
  3. Pedir cosas que no existen. Sí, me han preguntado por experiencia en “Azure SSMS”. No existe. También he visto peticiones de “conocimiento en procedimientos triggers” (¿?) o “optimización de tablas SQL BI” (lo que quiera que eso signifique).
  4. No diferenciar versiones ni entornos. SQL Server 2008 no es lo mismo que SQL Server 2019. Trabajar on-prem no tiene nada que ver con gestionar instancias en Azure SQL Database. Acláralo en la oferta. Y si no lo sabes, pregunta.

Glosario básico para RRHH sin miedo a SQL

Aquí tienes una lista de términos que deberías reconocer, aunque sea para no pronunciar mal en una entrevista. No hace falta que los expliques, pero sí que te suenen:

  • SQL: Es el lenguaje universal de consultas en las bases de datos relacionales.
  • SQL Server: Es el servidor de bases de datos relacionales de Microsoft. Otros servidores de bases de datos son Oracle, MySQL o PostgreSQL. No son lo mismo aunque hacen más o menos lo mismo. Gestionar bases de datos.
  • Índice: estructura que acelera la búsqueda de datos. Como un índice en un libro. Si no lo hay, todo va más lento.
  • Consulta / Query: es el código SQL que se lanza para obtener o modificar datos. “SELECT * FROM…” es un clásico.
  • Stored Procedure: código SQL almacenado en la base de datos, que encapsula lógica de negocio o consultas complejas.
  • Backup / Restore: copia de seguridad y su recuperación. Sin esto, todo lo demás da igual. Pregunta por esto siempre.
  • Job: tarea programada que se ejecuta en el servidor de base de datos. Sirve para automatizar procesos.
  • ETL / ELT: extracción, transformación y carga de datos. Básico en entornos de integración y reporting.
  • T-SQL: dialecto de SQL propio de Microsoft SQL Server. No es igual que PL/SQL (Oracle) ni que el de PostgreSQL (PG/SQL).
  • Instancia / Servidor / Motor: conceptos que conviene no confundir. Una instancia es una instalación del motor de base de datos, que puede convivir con otras en el mismo servidor físico o virtual.
  • Alta disponibilidad (HA): técnicas para asegurar que la base de datos siga funcionando aunque haya fallos.
  • Licenciamiento: aquí es donde empieza el dolor. SQL Server se licencia por núcleo, y en la nube cada modelo cambia.
  • On-prem / Cloud / Híbrido: dónde vive la base de datos. En tu infraestructura, en la nube, o una mezcla.
  • Monitorización: observar en tiempo real qué pasa en la base de datos. Métricas, alertas, salud del sistema.
  • Tuning / Plan de ejecución: afinar consultas lentas, revisar cómo se ejecutan internamente y optimizarlas.
  • Always On: Es una solución de Alta Disponibilidad avanzada propia de SQL Server.

Cómo no hacer el ridículo en una entrevista técnica

Muchas veces me ha pasado que me llama un reclutador al que han dado una lista de deseos y se ve que es la primera vez que lee alguno de los términos. Es que hasta se traban al leer las palabras técnicas raras. No se trata de fingir que sabes. Eso se nota. Pero tampoco de leer la oferta delante del candidato y esperar que te la explique. Aquí algunos consejos:

  • Haz preguntas abiertas. Por ejemplo: “¿Qué tareas asumías como DBA en tu anterior puesto?”, en vez de recitar tecnologías.
  • Escucha palabras clave. Si te dicen que hacían backups, mantenimiento, planes de ejecución… vas por buen camino.
  • No interrumpas con tecnicismos que no manejas. Si el candidato menciona un término que no conoces, anótalo y consulta después. Preguntar “¿y eso es como un Excel, pero en la nube?” no ayuda.
  • Si hay técnico en el equipo, involúcralo. Un screening técnico a tiempo evita semanas de procesos mal encaminados. 
  • Entiende lo que buscas. No se trata de que seas un experto pero lee antes la oferta, busca en google los conceptos que no entiendas. No tienes que profundizar pero, por lo menos que te suene de qué va la cosa.
  • Y sobre todo, no improvises. Si el perfil es muy técnico y no sabes por dónde empezar, reconoce tus límites. No es debilidad. Es profesionalidad.

Conclusión

Buscar talento técnico sin entender lo que se busca no solo alarga el proceso, sino que lo devalúa. Quien sabe del tema nota al vuelo cuándo quien lo entrevista no ha leído ni entendido la mitad del puesto. Si el candidato es bueno, se irá. Y si no se va, pregúntate por qué.

Este artículo no pretende convertirte en DBA, ni falta que hace. Pero sí ayudarte a no tratar a todos los perfiles SQL como si fueran lo mismo. Porque no lo son. Y porque si seguimos publicando ofertas imposibles, al final lo único que vamos a reclutar… es silencio.

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
29
Sep
2025

¿Junior, Senior o “experto”? El teatrillo de los títulos

Pocas cosas generan más debate en una comunidad técnica que intentar definir qué significa ser junior, senior o experto. Bueno, quizás si un MERGE en producción está justificado… pero eso es otro tema del que ya hablaremos. Hoy vamos a hablar de galones o etiquetas, como queráis llamarlo, de cómo se reparten sin criterio y de por qué seguimos viendo ofertas para “junior con 3 años de experiencia” como si eso tuviera sentido alguno. Y es que para mí no lo tiene.

Junior no es sinónimo de becario

Vamos al grano. Un perfil junior no es alguien que no sepa nada. Es alguien que está empezando, sí, pero con una base ya formada, aunque sea mínima. No es un becario que necesita que le expliquen qué es un JOIN, pero tampoco es alguien que se siente cómodo optimizando una consulta compleja en un entorno con 3.000 conexiones simultáneas.

El problema es que muchas empresas confunden junior con “alguien barato que haga lo que un senior, pero por la mitad del sueldo”. Ahí vienen esas ofertas delirantes que piden de 1 a 3 años de experiencia, conocimiento de media docena de tecnologías, disponibilidad 24/7 y espíritu “proactivo”. Y todo eso, claro, a cambio de un salario que apenas supera al de prácticas. La trampa es evidente: quieren que hagas de todo, cobres poco y no te quejes. Si encima sonríes, mejor.

Pongamos un ejemplo concreto en nuestro terreno. El junior DBA es el encargado de realizar tareas totalmente procedimentadas sin salirse del guión. No se le puede exigir más. Es el que aún lanza un BACKUP DATABASE desde Management Studio, feliz de ver el mensaje de éxito, sin pensar en restaurarlo después para comprobar que realmente sirve. Y cuando falla, su primera reacción es: “pero si la copia terminó sin errores”. Es normal, es parte del camino, pero ahí está la diferencia.

Y ojo, no es que tener 2 o 3 años de experiencia te haga automáticamente senior. Ni mucho menos. Pero llamar junior a alguien que lleva 3 años comiéndose marrones de producción es no entender nada.

Logo SoyDBA

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Senior no es el junior que lleva más tiempo

La etiqueta de senior se ha convertido en una medalla que muchos se cuelgan demasiado pronto. Como si el calendario fuera el único juez válido. Y no. Ser senior implica haber visto cosas. Muchas cosas. Implica haber roto entornos, haberlos arreglado, haber tomado decisiones técnicas difíciles y haber lidiado con sus consecuencias. Ser capaz de evaluar el coste de una mala decisión antes de que reviente todo un domingo a las 3AM.

Un ejemplo de DBA senior: sabe que hacer un BACKUP no es suficiente, que hay que automatizar la validación de restauraciones, que conviene pensar en RPO y RTO antes de que el CTO lo pregunte, y que poner todos los backups en la misma SAN que la base de datos es tan útil como poner un extintor dentro del fuego. Además, cuando revisa un plan de ejecución, no se queda en el dibujito bonito: entiende qué decisiones está tomando el optimizador y sabe cuándo necesita una intervención manual.

No necesariamente dará la solución más elegante, pero sí una que funcione, que no comprometa la seguridad y que no mate el rendimiento del sistema. Porque un senior de verdad no solo sabe lo que hace, sino por qué lo hace. Y lo más importante: también sabe cuándo no hacerlo.

Las horas que se cuentan (o no se cuentan)

Aquí entra uno de los mitos más persistentes del sector: las dichosas 5.000 horas para ser senior, y las 10.000 para ser experto. Un concepto que hemos heredado casi como dogma y que muchos repiten como si fuera una verdad revelada. La famosa teoría de la práctica deliberada que, si alguna vez tuvo sentido en el contexto del violín o el ajedrez, se ha degenerado por completo en el mundo técnico.

Porque no, no basta con acumular horas para ser mejor. Si tu jornada consiste en encender el PC, abrir Management Studio y hacer lo mismo que hiciste ayer, anteayer y hace dos años, entonces lo que estás sumando no son horas de experiencia, sino horas de repetición. Y eso no te convierte en senior. Te convierte en alguien que sabe repetir procesos.

La práctica solo te lleva a la maestría cuando es desafiante, consciente y dirigida a mejorar. Si no hay errores, reflexión y aprendizaje, da igual cuántas horas pongas: seguirás en el mismo punto. He visto gente con 2.000 horas de trabajo real, bien guiado, bien sufrido y bien reflexionado, que vale más que otros con 15.000 horas de pulsar “Next” en el asistente de instalación.

Así que si alguien te dice que ya ha superado las 10.000 horas y por tanto es experto, pregúntale si puede explicarte qué hace exactamente el Cardinality Estimator en SQL Server o cómo se comporta el Query Store bajo una carga de lectura intensiva. Si pone cara de “eso no lo he tocado”, ya tienes la respuesta.

El mito del experto

Y luego están los expertos. Esa palabra maldita que ha perdido su valor en LinkedIn. Todo el mundo es “experto” en algo. Hay quienes se autodefinen expertos en SQL Server por haber creado 4 procedimientos almacenados, un par de vistas y haber leído la documentación de sp_whoisactive.

Aquí conviene diferenciar. Un experto funcional puede ser brillante operando un entorno concreto: conoce de memoria las rutinas de mantenimiento, maneja la seguridad de usuarios sin pestañear, y sabe cómo lidiar con el sistema en el día a día. Pero un experto técnico va un paso más allá: entiende las tripas, cómo funciona realmente el optimizador de consultas, cómo afectan las estadísticas al plan de ejecución, o por qué tu índice columnstore se viene abajo con ese patrón de inserción masiva.

Ambos perfiles son valiosos, pero no son lo mismo. Y lo que más abunda son los que creen que ser expertos funcionales les convierte en gurús universales. Y no es así.

Un experto de verdad también sabe cuándo callarse y escuchar. Porque cuanto más sabes, más consciente eres de lo que te queda por aprender. Así de simple.

¿Y los niveles intermedios?

Esto es algo que muchas organizaciones siguen sin entender. No todo el mundo entra en la categoría binaria de junior o senior. Hay una progresión natural, pero parece que da miedo nombrarla. Habría que hablar más de perfiles middle, semi-senior, advanced junior o como demonios queramos llamarlos, pero con definiciones claras y expectativas razonables.

Piénsalo en términos prácticos: un middle DBA ya ha gestionado despliegues, se ha peleado con deadlocks y sabe cómo monitorizar correctamente el entorno. No es alguien a quien quieras dejar al mando de una arquitectura distribuida en microservicios con réplicas en 4 regiones de Azure, pero tampoco es el novato que lanza un TRUNCATE en producción sin comprobar antes si hay backup.

La falta de estas categorías intermedias genera frustración. Los juniors que progresan se sienten estancados, y los seniors reales se queman porque tienen que apagar fuegos sin ayuda suficiente. Así que sí, necesitamos más niveles, pero sobre todo, más claridad y menos ego en las etiquetas.

La falacia de la experiencia acumulada

Este es otro punto clave. Tener 5 años de experiencia no significa nada si has pasado esos 5 años repitiendo el mismo trabajo que hacías el primer mes. Lo que tienes entonces no son 5 años de experiencia, sino 1 mes de experiencia repetido 60 veces. Y eso, lo siento, no es lo mismo.

La experiencia que cuenta es la que desafía, la que te obliga a aprender algo nuevo, a tomar decisiones, a equivocarte y mejorar. Si tu trabajo durante años ha sido ejecutar tareas repetitivas en una base de datos que ni siquiera entiendes, difícilmente puedes reclamar el título de senior.

Y sí, esto pasa más de lo que creemos. Entornos donde la innovación técnica es nula, donde todo se hace igual “porque siempre ha funcionado”, y donde el único cambio en cinco años ha sido cambiar de proveedor de café. Luego llega alguien con 2 años en un entorno exigente y en 6 meses demuestra más criterio que tú. Duele, pero es real.

Entonces, ¿cómo se pasa de junior a senior, y de senior a experto?

Pasar de junior a senior requiere algo más que cumplir con lo que te encargan durante mucho tiempo. Hacer backups, monitorizar jobs o ejecutar scripts que te da otro está bien, pero no es suficiente. El salto se produce cuando empiezas a cuestionar lo que haces, a entender por qué se hace de una manera y no de otra, y a proponer alternativas. Un junior ejecuta. Un senior piensa y decide. Ese cambio de chip no viene solo con las horas, viene con iniciativa y curiosidad técnica.

Si eres junior, ten iniciativa. Pégate a los senior y a los expertos, y que te expliquen lo que hacen y por qué. Cuando escales una incidencia, pregunta si puedes participar en la solución. No siempre la carga de trabajo lo va a permitir, pero cuando se pueda, la mayoría de los buenos profesionales estarán encantados de explicarte las cosas. Y créeme: no tengas miedo a preguntar. Nadie que merezca la pena tiene miedo a que aprendas y le quites el trabajo. Al contrario: queremos que mejores para que puedas hacer más cosas tú, y nosotros podamos vivir mejor. Porque un equipo fuerte se construye compartiendo, no guardando secretos como si fueran recetas de la abuela.

Luego está el paso de senior a experto. Aquí la cosa se complica, porque ya no se trata solo de resolver problemas en tu día a día, sino de anticiparlos. El experto sabe detectar patrones, entender tendencias y diseñar sistemas para que el fuego no llegue a prenderse. Y, además, sabe explicarlo a otros. Porque si no eres capaz de transmitir tu conocimiento, tu “expertise” se queda en ego. Un verdadero experto enseña, documenta, comparte. Ahí está parte de la diferencia.

¿Y hace falta dar un “extra” fuera del trabajo? Seamos claros: sí. Si te limitas a lo que ves en tu jornada laboral, avanzarás, pero despacio, muy despacio. El que llega más lejos es el que dedica tiempo a seguir estudiando, probando, rompiendo cosas en entornos de pruebas, leyendo papers, explorando novedades y enfrentándose a problemas que quizás no le toquen aún. La gente que crece es la que tiene curiosidad más allá de su checklist diario.

Ojo, tampoco se trata de romantizar las jornadas interminables de autoestudio como si fueran la única vía. No es sano ni sostenible trabajar 8 horas y estudiar otras 8. Pero la realidad es que los mejores profesionales que he conocido no apagaban el ordenador al terminar de trabajar y se olvidaban de todo. Seguían investigando, aunque fuera con un proyecto personal, un curso puntual o trasteando con la última versión de SQL Server en una máquina virtual.

Con todo esto, ¿qué valor tiene realmente una etiqueta?

La respuesta honesta es, depende de quién la use y para qué. Para muchos reclutadores es simplemente un filtro. Algunos managers se lo toman como una excusa para pagar menos. Para los técnicos, un arma de doble filo: puede abrirte puertas o hacer que te pidan milagros.

Pero hay algo que no cambia: los títulos no te salvan cuando el clúster se cae, cuando hay que restaurar un backup sin dormir o cuando el rendimiento se desploma sin motivo aparente. En esos momentos, solo cuenta lo que sabes hacer. Y lo que sabes transmitir.

Porque si algo he aprendido después de más de una década en este mundo, es que el respeto profesional no se gana con etiquetas, sino con hechos. Con decisiones acertadas bajo presión, con humildad para reconocer errores y, sobre todo, con ganas de seguir aprendiendo aunque tengas el CV lleno de palabras bonitas.

Y aquí viene la idea final: ser junior, senior o experto no es un estado fijo. Es un proceso continuo. Hoy puedes ser senior en SQL Server 2019, pero si dejas de aprender, mañana serás el que se quedó atascado en técnicas de hace una década. El mercado no espera a nadie, y el conocimiento tampoco.

Conclusión

Las etiquetas junior, senior y experto seguirán existiendo, pero lo importante es no tomárselas demasiado en serio. Sirven como orientación, sí, pero no son la verdad absoluta. Mucho menos en un sector donde el conocimiento evoluciona a la velocidad del rayo y donde lo que hoy dominas, mañana está obsoleto.

Así que, la próxima vez que alguien te diga que es senior porque ha superado las 5.000 horas, o experto por las 10.000, recuerda que también hay quien cree que el MERGE bien hecho existe. Nosotros no lo hemos visto. Pero tampoco hemos visto unicornios.

Publicado por Roberto Carrancio en Otros, 2 comentarios