Cada vez que veo una oferta de trabajo que pide un DBA todoterreno con experiencia en SQL Server, Oracle, PostgreSQL, MySQL, MongoDB, Sybase, Cassandra y, de paso, conocimientos en DevOps, Kubernetes, Power BI, scripting en Python y algo de tuning en SAP HANA, me pregunto si están contratando a un administrador de bases de datos o a un grupo de consultores disfrazado de persona.
Estas ofertas no son una excepción puntual. Son ya una categoría en sí mismas. Y no es que me asuste el conocimiento transversal, al contrario: todos empezamos tocando varios palos. El problema es otro. El problema es que esta tendencia a buscar perfiles “todoterreno” está erosionando algo esencial: la profundidad técnica.
Generalistas en soporte, especialistas en producción
Tener una visión amplia de varios motores tiene su valor. Es útil en entornos donde la diversidad tecnológica es real, o en roles de soporte de primer nivel donde lo importante es reconocer patrones, detectar errores frecuentes y saber cuándo escalar. En ese contexto, un DBA generalista puede cumplir perfectamente su función. No es el que resuelve el problema más complejo, pero sí el que lo identifica antes de que se agrave.
Ahora bien, cuando pasamos a producción real, de esa que duele cuando falla, la historia cambia. En entornos donde una caída significa pérdida de negocio o una consulta mal diseñada cuesta cientos de euros en recursos, lo que marca la diferencia no es haber leído la documentación de tres motores distintos. Es conocer a fondo cómo piensa uno de ellos. Qué decisiones toma el optimizador, cómo se gestionan los bloqueos internos, qué implica realmente un ROLLBACK en una transacción de 200 GB, o cómo se comporta el almacenamiento ante ciertos patrones de acceso.
Es ahí donde entra el especialista. Ese DBA que no solo sabe qué está pasando, sino por qué. Que no necesita revisar los logs durante una hora porque ya ha visto ese fallo antes. Que no tiene que adivinar cómo reacciona el motor ante un plan de ejecución aberrante porque conoce su funcionamiento interno al detalle.
Y eso, por mucho que lo disfracemos con etiquetas como “perfil híbrido” o “dev-friendly”, no se consigue tocando siete tecnologías a la vez. Se consigue con foco, con años, con sangre (figurada), sudor (literal) y muchas noches leyendo documentación técnica mientras medio mundo duerme.
La falsa promesa del todoterreno que sabe de todo
Lo curioso es que esta demanda de omnisciencia técnica no viene solo de recursos humanos. Muchas veces nace del propio sector, de una cultura en la que parecer que sabes de todo vale más que saber realmente de algo. Como si el valor de un profesional se midiera por la longitud de su perfil en LinkedIn y no por la calidad de las decisiones que toma cuando todo se viene abajo.
El problema no es querer aprender de todo. Eso está bien. Lo peligroso es querer ser experto en todo. Porque eso es sencillamente imposible. Y quien lo intenta, acaba acumulando conocimientos superficiales que no resisten la presión de producción. Sabe ejecutar, pero no explicar. Identifica errores, pero no los entiende. Y eso, en el mejor de los casos, es ineficaz. En el peor, es directamente peligroso.
Yo no necesito un DBA que sepa hacer un poco de todo si cuando de verdad importa no distingue entre un latch y un wait. Prefiero al que lleva decenas de miles de horas trabajando con SQL Server, que ha visto servidores arder (a veces de forma figurada y otras casi literalmente) y sabe que el plan de mantenimiento de índices no es una tarea semanal sino una decisión estratégica.
Por desgracia, el mercado aún no valora como debería esa profundidad. Sigue prefiriendo perfiles con veinte tecnologías mencionadas y cero responsabilidades asumidas. Pero los equipos técnicos, los de verdad, los que dan soporte a entornos críticos, sí saben lo que vale un especialista. Y cuando hay que elegir entre uno que sabe un poco de todo y otro que domina lo que importa, no lo dudan.
Una nota para RRHH y responsables técnicos: el perfil ideal no existe
Si trabajas en selección o lideras un equipo técnico, este mensaje también va para ti. Es comprensible querer encontrar al “candidato ideal”, pero cuidado con convertirlo en una fantasía técnica. Las ofertas que piden un DBA que domine cinco motores distintos, tres entornos cloud, monitorización avanzada, DevOps y BI… no están buscando una persona. Están buscando una quimera.
La versatilidad es útil, claro. Pero en producción real, lo que necesitamos es profundidad. Y la profundidad no nace de tocar muchas cosas por encima, sino de meterse hasta el cuello en una tecnología concreta, convivir con ella en sus buenas y malas épocas, y saber exprimirla cuando toca.
Si pedís a alguien que haga todo, no hará nada bien. Y lo peor: los que realmente saben no aplicarán. Porque el que lleva años con SQL Server o con Oracle y tiene criterio técnico para tomar decisiones críticas no va a perder el tiempo en una oferta que parece escrita por un generador automático de palabras clave.
Cuando diseñéis el perfil, pensad en lo que de verdad necesitáis. ¿Hace falta experiencia real en alta disponibilidad en SQL Server? Entonces no pongáis “conocimientos en MySQL valorables” como si fuera un bonus simpático. Si el core del trabajo es PostgreSQL, no tiene sentido exigir 5 años con Mongo. Sed específicos. Y sobre todo, sed realistas.
El valor está en la profundidad, no en la dispersión
Hay una diferencia importante entre aprender y pretender. Aprender de varios motores, entender qué los distingue, explorar sus filosofías y herramientas, es una fase lógica y necesaria en el camino de cualquier DBA. Pero en algún punto hay que tomar decisiones. Elegir un stack, profundizar, construir criterio técnico.
Ese paso, que para algunos parece una renuncia, en realidad es lo que convierte a un profesional en alguien verdaderamente valioso. No porque sea incapaz de aprender otra cosa, sino porque ha decidido invertir su tiempo donde realmente puede marcar la diferencia.
Y esto no es una apología del inmovilismo. No se trata de quedarse atrapado en una tecnología por comodidad. Se trata de entender que el dominio técnico requiere tiempo, foco y profundidad. No se puede ser referente en cinco motores distintos a la vez. Y si alguien lo afirma… bueno, probablemente también cree que los NOLOCK solucionan bloqueos.
Conclusión
No hay nada malo en explorar varios caminos. Pero si queremos ser profesionales sólidos, de esos que se buscan cuando algo se rompe de verdad, en algún momento hay que elegir dónde cavar más hondo.
Un DBA indispensable no es el que sabe instalar todo lo que existe, sino el que entiende su entorno como nadie más. Ese que no improvisa, sino que anticipa. Que no copia soluciones, sino que las construye. Y eso no lo da la amplitud. Lo da la profundidad.
Así que, si estás empezando, aprende de todo lo que puedas. Pero no te quedes ahí. Y si ya llevas años, quizá va siendo hora de preguntarte: ¿quieres ser uno más en todas partes o el que marca la diferencia donde realmente importa?
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 LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
