Una plataforma de servicios financieros con crecimiento sostenido pasó dos años sin nadie a cargo de sus bases de datos. Funcionaba: el motor estaba en la nube, el proveedor manejaba los respaldos automáticos y el equipo de desarrollo escribía sus propias consultas. Hasta que un martes de cierre de mes la aplicación empezó a responder en doce segundos, el equipo pasó dos días revisando el código de la aplicación y al tercer día alguien descubrió que una tabla de transacciones había crecido a niveles que ningún índice cubría. Restaurar el rendimiento tomó una semana. Cuando el directorio preguntó quién era el responsable de la base de datos, la respuesta honesta fue que nadie: todos la usaban y ninguno la administraba. El costo de esa vacante invisible se pagó en un solo incidente.
Contratar un DBA (administrador de bases de datos) o Database Engineer es una decisión que muchas empresas postergan porque asumen que la nube ya resolvió el problema. La nube resolvió la instalación y el respaldo, no el diseño, el rendimiento, el costo ni la recuperación ante desastre. Esta guía de IT Workers ordena la decisión para un decisor no técnico: qué hace realmente un administrador de bases de datos moderno, en qué se diferencia de un Data Engineer, de un SRE y de un desarrollador de backend, cuándo aparece la necesidad, cómo evaluar criterio de rendimiento, continuidad y seguridad sin dominar la técnica, qué estructura de entrevista filtra de verdad y qué rangos de renta considerar en 2026.
El público objetivo es CTO, Gerente de TI, Head of Engineering, Gerente de Operaciones y Gerente de Personas. Sin jerga innecesaria. Los rangos numéricos que aparecen más adelante son referenciales de mercado 2026 y llevan su disclaimer al inicio del bloque que los usa.
1. Qué hace realmente un DBA moderno
Un administrador de bases de datos moderno responde por la salud, el rendimiento, la continuidad y el costo del lugar donde vive el dato de la compañía. El estereotipo de la persona que instala el motor y programa respaldos describe un oficio que efectivamente desapareció; lo que reemplazó a ese oficio es más exigente. Se descompone en cinco frentes. Primero, diseño y modelado físico: cómo se estructuran las tablas, los índices y las particiones para que el sistema aguante el crecimiento previsto. Segundo, rendimiento: diagnosticar por qué una consulta que ayer tomaba cincuenta milisegundos hoy toma ocho segundos, y corregirlo en el lugar correcto. Tercero, continuidad: respaldos que se prueban restaurando de verdad, replicación, alta disponibilidad y un plan de recuperación con tiempos comprometidos. Cuarto, seguridad y cumplimiento: control de accesos, cifrado, enmascaramiento de datos sensibles y trazabilidad de quién vio qué. Y quinto, costo: en la nube, una base mal diseñada se paga cada mes en la factura.
Lo que distingue a un profesional senior de bases de datos de uno operativo es dónde busca la causa. El senior sabe leer un plan de ejecución, entiende el impacto de un cambio de esquema sobre un sistema en producción y anticipa el problema antes del incidente, con métricas y umbrales. El operativo reacciona: reinicia, agrega recursos y espera que el proveedor de nube absorba el problema. La diferencia se paga en incidentes evitados, en factura de infraestructura y en la velocidad con la que el equipo de desarrollo puede avanzar sin miedo a tocar el esquema.
La nube no eliminó el rol, lo movió
Los servicios administrados de base de datos automatizaron las tareas repetitivas: instalación, parches, respaldos programados y alta disponibilidad básica. Lo que no automatizaron es el criterio. Ningún servicio decide por la empresa cuál es el modelo de datos correcto, qué índice conviene, cómo particionar una tabla que crece sin control, qué tiempo de recuperación es aceptable para el negocio o si el motor elegido sigue siendo el adecuado tres años después. Esa capa de criterio es exactamente donde un buen administrador de bases de datos genera valor, y es la que ninguna empresa nota que le falta hasta que ocurre el primer incidente serio o llega una factura de nube que nadie sabe explicar.
2. DBA vs Data Engineer vs SRE vs desarrollador backend
Los cuatro perfiles tocan bases de datos y por eso se confunden en los procesos de selección. La regla mental es simple: el DBA responde por la base de datos operacional que sostiene las aplicaciones; el Data Engineer construye las tuberías que mueven datos hacia el almacén analítico; el SRE responde por la confiabilidad de todo el sistema en producción; el desarrollador de backend escribe el código que consulta la base. Los cuatro pueden escribir una consulta, pero solo uno responde cuando la base se cae a las tres de la mañana. La tabla siguiente compara las cuatro figuras en las dimensiones que importan al decidir a quién contratar.
| Dimensión | DBA / Database Engineer | Data Engineer | SRE | Backend Engineer |
|---|---|---|---|---|
| Foco principal | Base de datos operacional sana y rápida | Pipelines hacia el almacén analítico | Confiabilidad del sistema completo | Lógica de negocio de la aplicación |
| Pregunta que responde | ¿Aguanta, responde y se puede recuperar? | ¿El dato llega limpio al almacén? | ¿El servicio cumple su nivel de servicio? | ¿La funcionalidad hace lo que debe? |
| Output típico | Modelo físico, índices, plan de recuperación | Ingestas, transformaciones, orquestación | Observabilidad, automatización, respuesta a incidentes | Servicios, APIs, pruebas |
| Momento crítico | Degradación de rendimiento o pérdida de datos | Quiebre de un pipeline o dato inconsistente | Caída de producción | Entrega de funcionalidad |
| Riesgo si falta | Incidentes silenciosos y factura fuera de control | No hay analítica confiable | Nadie responde por la disponibilidad | No avanza el producto |
En equipos pequeños es habitual y sano que el rol sea compartido: un ingeniero de plataforma con criterio de bases de datos puede cubrir la función durante años. El problema aparece cuando nadie lo tiene formalmente asignado, porque las tareas de administración de bases de datos son invisibles hasta que fallan. Los perfiles vecinos están descritos en cómo contratar un Data Engineer, en cómo contratar un SRE y en cómo contratar un Platform Engineer.
3. Cuándo una empresa necesita un DBA
La necesidad de un administrador de bases de datos rara vez se declara en un plan de dotación: aparece como una acumulación de síntomas que el equipo aprende a normalizar. Seis señales son las más confiables.
Seis señales de que llegó el momento
- El rendimiento se degrada y nadie sabe por qué. Consultas que antes eran instantáneas ahora demoran, y la respuesta habitual del equipo es agregar más recursos de infraestructura en vez de encontrar la causa.
- Los respaldos nunca se han probado restaurando. Existe una política de respaldo, pero nadie ha ejecutado una restauración completa en un ambiente aparte para verificar que el respaldo sirve y cuánto demora.
- La factura de nube crece más rápido que el negocio. El costo de almacenamiento y cómputo de las bases sube cada trimestre sin que nadie pueda explicar qué lo empuja ni proponer una optimización.
- Los cambios de esquema dan miedo. El equipo posterga modificaciones a las tablas porque no hay confianza en el impacto, lo que frena el desarrollo del producto y acumula deuda técnica.
- Hay datos sensibles sin gobierno de accesos. Varias personas tienen credenciales amplias sobre producción, no existe trazabilidad de consultas y los ambientes de prueba usan datos reales sin enmascarar.
- Cada incidente resulta ser la base de datos. Las caídas del último año tienen un patrón común y la respuesta operativa siempre es la misma: reiniciar y esperar.
La señal inversa también existe. Si la empresa tiene una aplicación con volumen moderado, usa un servicio administrado, tiene un equipo de plataforma competente y ningún incidente atribuible a la base, contratar un especialista a tiempo completo puede ser prematuro. En ese escenario suele rendir más asignar formalmente la responsabilidad a alguien del equipo, contratar apoyo especializado por horas para una revisión anual y reevaluar cuando el volumen o el riesgo cambien. Lo que no funciona es dejar el rol sin dueño.
4. Cómo evaluar a un DBA sin ser técnico
La buena noticia para un decisor no técnico es que las competencias que definen a un buen profesional de bases de datos se evalúan escuchando cómo razona frente a un incidente, no revisando sintaxis. Lo que se juzga es método de diagnóstico, disciplina de continuidad y criterio de riesgo. Cinco competencias permiten separar a un especialista senior de uno operativo, y todas se evalúan pidiendo casos concretos del pasado.
- Diagnóstico de rendimiento: tiene un método para encontrar la causa, no una lista de trucos. Un buen profesional describe cómo aisló el problema con evidencia; uno débil cuenta que agregó recursos hasta que dejó de doler.
- Continuidad y recuperación: distingue entre tener respaldos y poder restaurar, y conoce los tiempos comprometidos con el negocio. Un buen perfil ha ejecutado restauraciones de prueba; uno débil confía en que el proveedor lo cubre.
- Diseño y modelado físico: anticipa cómo se comporta el modelo cuando el volumen se multiplica. Un buen profesional explica una decisión de índice o partición y su costo; uno débil normaliza o desnormaliza por costumbre.
- Seguridad y control de accesos: gobierna quién accede a qué, con trazabilidad y datos enmascarados fuera de producción. Un buen perfil trae el tema sin que se lo pregunten; uno débil lo trata como responsabilidad de otro equipo.
- Colaboración con desarrollo: ayuda al equipo a escribir mejor código en vez de bloquearlo. Un buen profesional cuenta cómo cambió una práctica del equipo; uno débil se define por lo que no deja hacer.
Green flags y red flags
Las green flags más fiables: el candidato describe un incidente real con su línea de tiempo, hipótesis descartadas y causa final; distingue con claridad entre respaldo y restauración probada; menciona el costo de infraestructura como una variable propia; pregunta por los tiempos de recuperación aceptables para el negocio antes de proponer una arquitectura; y explica cómo enseñó al equipo de desarrollo a evitar un patrón dañino. Las red flags: atribuye todos los problemas al código de otros; nunca ha restaurado un respaldo completo; se define por un solo motor de base de datos y descalifica el resto; no tiene una posición sobre control de accesos; y describe su rol como el de quien aprueba o rechaza cambios. Un marco general para evaluar perfiles tech sin ser técnico está en cómo evaluar candidatos tech siendo no técnico.
La base de datos es el único componente de la arquitectura donde un error no se revierte con un despliegue. Por eso un buen administrador de bases de datos no se evalúa por los motores que conoce, sino por la última vez que restauró un respaldo completo y midió cuánto demoró en dejar el negocio operativo.
Pablo Herrera · Founder & IT Headhunter en IT Workers5. Estructura de entrevista recomendada
Una entrevista de bases de datos improvisada se convierte en un examen de comandos, y ese examen no predice el desempeño. Un proceso estructurado con etapas claras y un scorecard común reduce el sesgo y hace comparables a los finalistas. La estructura siguiente cubre las cinco competencias y reparte la evaluación entre ingeniería, operaciones y personas.
| Etapa | Qué evalúa | Duración | Conduce |
|---|---|---|---|
| 1. Screening inicial | Experiencia, escala gestionada, motivación | 30 min | Recruiter o hiring manager |
| 2. Caso de incidente de rendimiento | Método de diagnóstico y priorización | 60 min | Líder de ingeniería o par senior |
| 3. Caso de continuidad y recuperación | Respaldos probados, replicación, tiempos comprometidos | 45 min | Líder de infraestructura o SRE |
| 4. Diseño y seguridad de datos | Modelado físico, accesos, datos sensibles | 60 min | Arquitecto o líder de plataforma |
| 5. Comportamental | Colaboración con desarrollo, manejo de presión | 30 min | Head of People o líder de área |
El caso de incidente de rendimiento es la etapa más reveladora y funciona incluso con un evaluador de negocio presente. Se plantea un escenario real: la aplicación empezó a responder lento el día de mayor carga del mes, no hubo despliegue reciente y el proveedor de nube reporta todo normal. Lo que se observa no es la solución, sino el método: qué mide primero, qué hipótesis descarta y con qué evidencia, cómo decide entre una corrección rápida y una estructural, y qué comunica al negocio mientras el problema sigue abierto. El caso de continuidad hace la pregunta que casi nadie hace en las entrevistas y que separa de inmediato a los perfiles serios: cuánto tiempo tomaría dejar el negocio operativo si la base principal se perdiera completa esta noche.
El scorecard común
Cada etapa debe cerrar con una evaluación escrita sobre criterios definidos de antemano. Un scorecard común permite que evaluadores con formación distinta juzguen con la misma vara y que la decisión final se sostenga en evidencia comparable. La metodología completa está en la guía de scorecard de contratación tech. Para definir el formato de la etapa práctica sin ahuyentar candidatos escasos, la comparación de formatos está en prueba técnica: take-home, live coding o diseño de sistema.
6. Rangos de renta de un DBA o Database Engineer
La renta de un profesional de bases de datos varía según industria, criticidad del sistema, volumen gestionado y si el cargo incluye o no responsabilidad de continuidad y turnos de disponibilidad. Cualquier número es un orden de magnitud, no una oferta. Conocer el rango evita dos errores frecuentes: ofrecer por debajo y quedarse con perfiles operativos cuando se necesita criterio, u ofrecer por encima sin necesidad cuando el alcance es acotado.
Los rangos que siguen son estimaciones referenciales de mercado 2026 elaboradas en base a procesos gestionados por IT Workers y no constituyen una oferta ni una garantía de compensación para ningún rol o empresa específica. Varían por industria, criticidad del sistema y alcance real del cargo.
| Nivel | Rango bruto mensual (CLP) | Responsabilidad típica |
|---|---|---|
| DBA junior (1-2 años) | $1.600.000 – $2.400.000 | Operación, monitoreo y tareas programadas |
| DBA semi senior | $2.400.000 – $3.500.000 | Rendimiento, respaldos y soporte a desarrollo |
| DBA senior / Database Engineer | $3.500.000 – $5.200.000 | Diseño físico, continuidad y optimización de costo |
| Database Reliability Engineer / Lead | $5.200.000 – $7.000.000 | Estrategia de datos operacionales y equipo |
| Arquitecto de datos | $6.500.000 – $9.000.000 | Arquitectura transversal operacional y analítica |
Banca, seguros, salud y plataformas con alto volumen transaccional tienden a pagar en el extremo superior, porque la exigencia de continuidad y cumplimiento normativo es mayor y el costo de un incidente es alto. El desglose por perfil vecino está en el sueldo de un Data Engineer 2026, en el sueldo de un SRE, en el sueldo de un DevOps Engineer, en el sueldo de un Cloud Engineer y en la guía salarial tech 2026, útil para calibrar la banda antes de hacer una oferta.
7. Errores comunes al contratar un DBA y cómo IT Workers acelera el proceso
Después de gestionar búsquedas de perfiles de infraestructura y datos en compañías con sistemas críticos, los errores que arruinan una contratación de bases de datos se repiten con claridad. Casi todos son evitables con un brief honesto y un proceso ordenado.
Los cinco errores más frecuentes
- Asumir que la nube reemplaza el rol. Los servicios administrados automatizan instalación y respaldo, no el criterio de diseño, rendimiento, recuperación ni costo. La vacante invisible se paga en el primer incidente serio.
- Buscar por motor específico y no por criterio. Exigir años exactos en un motor determinado descarta profesionales que diagnostican bien en cualquier plataforma y premia experiencia repetida sin profundidad.
- Contratar un perfil operativo para un problema de diseño. Cuando el dolor es un modelo que no escala, sumar alguien que monitorea y ejecuta tareas programadas no resuelve nada y deja el problema para el año siguiente.
- No preguntar nunca por restauración. Evaluar respaldos como una casilla administrativa, sin preguntar cuándo fue la última restauración probada ni cuánto demoró, es el filtro más barato que casi nadie aplica.
- Definir el rol como el guardián que dice que no. Un cargo planteado como control puro atrae perfiles defensivos y ahuyenta a los que colaboran con desarrollo, que son los que realmente mejoran el sistema.
IT Workers ejecuta búsquedas dirigidas de DBA, Database Engineers, Database Reliability Engineers y arquitectos de datos con un proceso que ataca estos errores de raíz. Parte de un brief preciso que distingue si el problema es de operación, de diseño o de continuidad; identifica candidatos pasivos que no responden avisos; los evalúa con un scorecard de competencias de bases de datos que incluye la pregunta de restauración; y presenta una shortlist en pocos días. Cada colocación incluye garantía de 90 días. Para empresas sin liderazgo técnico interno, además, traduce el riesgo de datos a criterios de decisión comprensibles para la gerencia. El enfoque general de búsqueda de perfiles tech se describe en reclutamiento de desarrolladores y perfiles tech y la especialidad de infraestructura en contratar perfiles DevOps y cloud. Otros materiales para el comité están reunidos en el hub de recursos para empresas.
8. FAQ: 12 preguntas frecuentes de empresas que contratan este perfil
¿Qué hace exactamente un DBA en 2026?
Un administrador de bases de datos moderno responde por la salud, el rendimiento, la continuidad, la seguridad y el costo de las bases donde vive el dato operacional de la compañía. Eso incluye diseño y modelado físico (tablas, índices, particiones), diagnóstico de degradaciones de rendimiento, respaldos que se prueban restaurando de verdad, replicación y alta disponibilidad, control de accesos y datos sensibles, y optimización del gasto de infraestructura. El estereotipo del profesional que solo instala el motor y programa respaldos describe un oficio que efectivamente desapareció: lo que quedó es un rol de criterio, más exigente y más caro de dejar vacante.
¿La nube no reemplazó al DBA?
No. Los servicios administrados automatizaron las tareas repetitivas: instalación, parches, respaldos programados y alta disponibilidad básica. Lo que no automatizaron es el criterio. Ningún servicio decide cuál es el modelo de datos correcto, qué índice conviene, cómo particionar una tabla que crece sin control, qué tiempo de recuperación acepta el negocio o si el motor elegido sigue siendo el adecuado tres años después. Además, en la nube una base mal diseñada se paga cada mes en la factura. La nube movió el rol desde la operación hacia el diseño y el gobierno, y lo volvió menos visible pero no menos necesario.
¿Cuál es la diferencia entre un DBA y un Data Engineer?
El DBA responde por la base de datos operacional que sostiene las aplicaciones en producción: rendimiento, continuidad, seguridad y costo. El Data Engineer construye las tuberías que mueven datos desde esos sistemas hacia el almacén analítico, para que la empresa pueda reportar y analizar. Ambos escriben consultas y modelan, pero el momento crítico de cada uno es distinto: el del DBA es una degradación de rendimiento o una pérdida de datos, el del Data Engineer es un pipeline quebrado o un dato inconsistente en el almacén. Contratar uno esperando el trabajo del otro es un error de matching frecuente y caro.
¿Cuándo una empresa necesita contratar un DBA?
Cuando el rendimiento se degrada y la respuesta habitual es agregar más recursos sin encontrar la causa, cuando los respaldos nunca se han probado restaurando, cuando la factura de nube crece más rápido que el negocio sin explicación, cuando los cambios de esquema dan miedo y frenan el desarrollo, cuando hay datos sensibles sin gobierno de accesos, o cuando los incidentes del último año apuntan siempre a la base. Si la empresa tiene volumen moderado, un servicio administrado y ningún incidente atribuible, puede bastar con asignar formalmente la responsabilidad y contratar apoyo especializado puntual.
¿Cómo se evalúa a un DBA sin ser técnico?
Un decisor no técnico evalúa este perfil escuchando cómo razona frente a un incidente, no revisando sintaxis. Cinco competencias son observables: método de diagnóstico de rendimiento, continuidad y recuperación probada, diseño y modelado físico anticipando crecimiento, seguridad y control de accesos, y colaboración con el equipo de desarrollo. El método es pedir un incidente real con su línea de tiempo, qué midió primero, qué hipótesis descartó y con qué evidencia. Un profesional sólido reconstruye la historia con datos. Uno operativo cuenta que agregó recursos hasta que el problema dejó de doler.
¿Qué pregunta filtra mejor a un candidato a DBA?
Una sola pregunta separa de inmediato a los perfiles serios: cuánto tiempo tomaría dejar el negocio operativo si la base principal se perdiera completa esta noche, y cuándo fue la última vez que ejecutó esa restauración de prueba. Un profesional sólido responde con un número, describe el procedimiento y menciona el ambiente donde lo probó. Uno débil responde que los respaldos están configurados y que el proveedor de nube lo cubre. La diferencia entre tener respaldos y poder restaurar es exactamente el tipo de criterio por el cual se contrata a este perfil, y casi ninguna empresa lo pregunta.
¿Qué red flags revelan a un mal candidato a DBA?
Las señales de alerta más fiables: atribuye todos los problemas al código escrito por otros equipos; nunca ha ejecutado una restauración completa de prueba; se define exclusivamente por un motor de base de datos y descalifica el resto sin argumentos; no tiene posición sobre control de accesos ni datos sensibles fuera de producción; no considera el costo de infraestructura como variable propia; y describe su rol como el de quien aprueba o rechaza cambios en vez de habilitar al equipo. Un cargo planteado como control puro, además, atrae justamente ese perfil defensivo.
¿Conviene un DBA interno o un servicio externo?
Un servicio externo funciona bien para revisiones periódicas, auditorías de rendimiento, migraciones acotadas y cobertura fuera de horario. No funciona como único responsable permanente, porque el conocimiento del modelo de datos y del comportamiento del sistema en producción queda fuera de la empresa y hay que volver a comprarlo en cada incidente. La combinación razonable para una compañía con sistemas críticos es responsabilidad interna clara, apoyada por un proveedor especializado en peaks y en horarios de baja cobertura. Lo que nunca funciona es que el rol no tenga dueño formal, porque estas tareas son invisibles hasta que fallan.
¿Un desarrollador backend puede hacer de DBA?
Puede cubrir la función en equipos pequeños y con volumen moderado, especialmente si tiene interés genuino en el tema y tiempo asignado. El problema no es la capacidad sino la prioridad: cuando la persona responde por entregar funcionalidad, las tareas de bases de datos siempre pierden frente a la fecha de entrega, y son tareas cuyo costo de postergación aparece meses después. Si la empresa toma este camino, conviene asignar la responsabilidad de forma explícita, reservar tiempo semanal para ella y contratar una revisión externa anual. La alternativa realista, al crecer, es un Database Engineer dedicado o un ingeniero de plataforma con ese foco.
¿Cuánto gana un DBA en el mercado local?
Los rangos varían por industria, criticidad del sistema y alcance del cargo, por lo que cualquier número es referencial. Como orden de magnitud bruto mensual en 2026: un administrador de bases de datos junior suele moverse entre 1,6 y 2,4 millones de pesos; un perfil semi senior entre 2,4 y 3,5 millones; un DBA senior o Database Engineer entre 3,5 y 5,2 millones; un Database Reliability Engineer o Lead entre 5,2 y 7 millones; y un arquitecto de datos entre 6,5 y 9 millones. Banca, seguros, salud y plataformas de alto volumen transaccional pagan en el extremo superior. Estos rangos son referenciales de mercado y no constituyen una oferta.
¿Cuáles son los errores más comunes al contratar un DBA?
Cinco errores se repiten. Asumir que la nube reemplaza el rol y dejar la función sin dueño formal. Buscar por años exactos en un motor específico en vez de por criterio de diagnóstico, lo que descarta a los mejores profesionales. Contratar un perfil operativo cuando el dolor real es un problema de diseño que no escala. No preguntar nunca por restauración probada, que es el filtro más barato y más revelador del proceso. Y definir el cargo como el guardián que aprueba o rechaza cambios, lo que atrae perfiles defensivos y ahuyenta a quienes colaboran con desarrollo y mejoran el sistema.
¿Cómo ayuda IT Workers a contratar un DBA?
IT Workers es una consultora B2B de headhunting tech que ejecuta búsquedas dirigidas de DBA, Database Engineers, Database Reliability Engineers y arquitectos de datos. El proceso parte de un brief preciso que distingue si el problema es de operación, de diseño o de continuidad; identifica candidatos pasivos que no responden avisos; los evalúa con un scorecard de competencias que incluye diagnóstico de rendimiento y restauración probada; y presenta una shortlist en pocos días. Cada colocación incluye garantía de 90 días. Para empresas sin liderazgo técnico interno, además, traduce el riesgo de datos a criterios de decisión comprensibles para la gerencia general.
¿Necesitas contratar un DBA o Database Engineer?
Conversación estructurada de 20 minutos para definir si el problema es de operación, de diseño o de continuidad, y calibrar el nivel correcto. Recomendación honesta sin venta forzada. Shortlist en pocos días con garantía de 90 días.
Hablar con un consultor WhatsApp directo- — PostgreSQL: documentación oficial de rendimiento y recuperación, 2024-2025
- — Google SRE: confiabilidad, objetivos de servicio y respuesta a incidentes, 2024
- — AWS Database Blog: prácticas de bases de datos administradas, 2024-2025
- — Percona: optimización de rendimiento y operación de bases de datos, 2024-2025
- — Get on Board, reportes de mercado tech LATAM, 2024-2025