Talently
Talently
DBA

DBA

Garantiza que los datos del negocio estén disponibles, íntegros y accesibles con el rendimiento que el producto requiere.

Un Database Administrator (DBA) es responsable de diseñar, implementar, mantener y optimizar los sistemas de bases de datos que sustentan los productos y operaciones de una organización. Su trabajo abarca desde el modelado de datos y la configuración de motores de bases de datos hasta la gestión de backups, replicación, alta disponibilidad y recuperación ante desastres. Trabaja estrechamente con desarrolladores backend, arquitectos y equipos de infraestructura para garantizar que los sistemas de datos soporten el crecimiento del negocio sin comprometer el rendimiento ni la integridad.

PostgreSQLMySQLMongoDBRedisSQLReplicación

Recluta al mejor DBA aquí

Empieza ahora

Responsabilidades Principales

  • •Diseñar y mantener esquemas de bases de datos relacionales y no relacionales optimizados para los patrones de acceso del producto.
  • •Monitorear y optimizar el rendimiento de queries, índices y configuración del motor para mantener tiempos de respuesta dentro de los SLAs.
  • •Implementar y mantener estrategias de backup, replicación y alta disponibilidad para garantizar continuidad del negocio.
  • •Gestionar migraciones de esquema en producción con estrategias que minimicen el downtime y el riesgo de pérdida de datos.
  • •Definir y aplicar políticas de seguridad de acceso a datos: roles, permisos, auditoría y cifrado.
  • •Colaborar con equipos de desarrollo revisando queries y diseños de esquema antes de que lleguen a producción.

Habilidades Clave

Technical Skills

  • Dominio avanzado de SQL: joins complejos, window functions, CTEs, subqueries y optimización de planes de ejecución
  • Administración de motores relacionales (PostgreSQL, MySQL) y no relacionales (MongoDB, Redis) incluyendo configuración y tuning
  • Diseño de esquemas con normalización, desnormalización estratégica y modelado de datos para OLTP y OLAP
  • Implementación de replicación, clustering y estrategias de alta disponibilidad (streaming replication, read replicas, failover automático)
  • Gestión de backups con estrategias de point-in-time recovery y pruebas periódicas de restauración
  • Monitoreo de rendimiento con herramientas como pg_stat_statements, slow query log, EXPLAIN ANALYZE y sistemas APM

Soft Skills

  • Rigor metodológico para ejecutar cambios en producción con checklists, validaciones previas y planes de rollback documentados
  • Comunicación técnica para traducir problemas de rendimiento de base de datos en impacto de negocio comprensible para stakeholders
  • Pensamiento preventivo para anticipar cuellos de botella antes de que el volumen de datos los haga evidentes
  • Capacidad de colaborar con desarrolladores cuestionando diseños de esquema o queries sin generar fricción innecesaria
  • Disciplina operacional para mantener documentación actualizada de configuraciones, decisiones de diseño y procedimientos de emergencia
  • Criterio para balancear la perfección técnica del esquema con la velocidad que el negocio requiere para evolucionar el producto

Casos de uso reales

Contexto

A medida que el volumen de datos crece, queries que funcionaban bien con miles de registros empiezan a degradarse. La optimización proactiva evita que el problema llegue a producción.

Ejemplos reales

  • Análisis de slow query log e identificación de queries sin índices adecuados
  • Diseño de índices compuestos para patrones de acceso específicos del producto
  • Particionamiento de tablas históricas para mantener el rendimiento con datos de años anteriores
  • Reescritura de queries con planes de ejecución ineficientes detectados con EXPLAIN ANALYZE

Contexto

Un esquema bien diseñado desde el inicio reduce la deuda técnica futura y facilita la evolución del producto. Un esquema mal diseñado es costoso de corregir una vez que hay datos en producción.

Ejemplos reales

  • Modelado entidad-relación con normalización adecuada al caso de uso
  • Decisión entre esquema relacional y documental según los patrones de acceso
  • Diseño de esquemas multi-tenant con aislamiento de datos por organización
  • Definición de constraints, foreign keys y checks que garantizan integridad en la base de datos

Contexto

Las bases de datos son el componente más crítico de la mayoría de los sistemas. Su caída afecta a toda la aplicación. La alta disponibilidad y el DR deben diseñarse antes de que ocurra el primer incidente.

Ejemplos reales

  • Configuración de streaming replication con failover automático en PostgreSQL
  • Implementación de read replicas para distribuir carga de lecturas
  • Estrategia de backups con pruebas de restauración periódicas y documentadas
  • RTO y RPO definidos y validados mediante simulacros de DR programados

Contexto

Cambiar el esquema de una base de datos con millones de registros y usuarios activos es una de las operaciones más riesgosas en producción. Requiere planificación, estrategia y validación exhaustiva.

Ejemplos reales

  • Migraciones zero-downtime con el patrón expand-contract
  • Backfills de columnas nuevas en tablas grandes con batches para evitar locks
  • Validación de integridad de datos antes y después de cada migración
  • Procedimientos de rollback documentados y probados antes de aplicar en producción

Contexto

Los datos son el activo más sensible de la organización. Las bases de datos deben tener controles de acceso estrictos, auditoría de operaciones y cifrado de datos sensibles.

Ejemplos reales

  • Modelo de roles y permisos con principio de mínimo privilegio por aplicación y usuario
  • Auditoría de accesos a tablas con datos PII o financieros
  • Cifrado de columnas sensibles y gestión de claves con integración a KMS
  • Enmascaramiento dinámico de datos para entornos de desarrollo y staging

Preguntas básicas

Normalizar para OLTP: reduce redundancia, garantiza integridad y facilita escrituras. Desnormalizar estratégicamente para OLAP o cuando las queries de lectura son frecuentes y el costo de los joins es medible en producción. La desnormalización siempre es una decisión consciente con su costo documentado: mayor complejidad en escrituras y riesgo de inconsistencia si no se gestiona correctamente.
Indexar columnas que aparecen frecuentemente en cláusulas WHERE, JOIN, ORDER BY o GROUP BY en queries de alto volumen. No indexar columnas con baja cardinalidad (pocos valores distintos) porque el índice no aporta selectividad. Considerar índices compuestos cuando las queries filtran por múltiples columnas juntas. Cada índice tiene un costo en escrituras y espacio; no se deben crear índices especulativos sin evidencia de que se usarán.
Ejecutar EXPLAIN ANALYZE para ver el plan real de ejecución: si hace sequential scan en lugar de index scan, si hay nested loops costosos, o si las estimaciones del planner difieren mucho de los valores reales. Revisar si las estadísticas están actualizadas con ANALYZE. Verificar si la query tiene parámetros que impiden el uso de índices (funciones sobre columnas indexadas, conversiones de tipo implícitas). Comparar el plan en staging con el de producción si difieren.
Backup lógico (pg_dump, mysqldump): exporta los datos como SQL o CSV. Portable entre versiones y motores, pero lento en restauración para bases de datos grandes. Backup físico (pg_basebackup, snapshots de volumen): copia los archivos del motor. Más rápido de restaurar y permite point-in-time recovery con WAL archiving. Para bases de datos de producción con requisitos de RPO bajo, el backup físico con PITR es la estrategia estándar.
Un deadlock ocurre cuando dos transacciones se esperan mutuamente para liberar un lock, bloqueándose indefinidamente. Los motores lo detectan automáticamente y abortan una de las transacciones. Se previene: accediendo siempre a los recursos en el mismo orden en todas las transacciones, manteniendo las transacciones cortas, y usando el nivel de aislamiento mínimo necesario. Se detecta en el log del motor (PostgreSQL registra deadlocks con deadlock_timeout).
Crear un usuario con permisos de solo lectura limitados a las tablas necesarias, con una ventana temporal de acceso. Registrar el acceso en el sistema de auditoría. Nunca dar acceso con el usuario de la aplicación ni con un superusuario. Si se necesita modificar datos, el cambio debe ser revisado, aprobado y ejecutado por el DBA, no directamente por el desarrollador. Revocar el acceso inmediatamente después de resolver el incidente.
Tres estrategias: base de datos separada por tenant (máximo aislamiento, mayor costo), schema separado por tenant en la misma BD (buen aislamiento, escalabilidad media), o tabla compartida con columna tenant_id (mayor escala, requiere row-level security para garantizar aislamiento). La elección depende del número de tenants, los requisitos de compliance y aislamiento, y el costo de infraestructura. Row-level security en PostgreSQL es una herramienta clave para la tercera estrategia.
Ejecutar la migración en una copia reciente de producción midiendo el tiempo real y los locks generados. Verificar que hay un plan de rollback probado. Comunicar la ventana de mantenimiento si hay impacto esperado. Ejecutar en horario de menor carga. Monitorear activamente métricas de la BD durante la migración. Tener listo el comando de rollback para ejecutar en segundos si algo falla. Nunca ejecutar una migración de producción que no se haya probado previamente.

Preguntas técnicas

Un B-tree mantiene los valores ordenados en una estructura de árbol balanceado que permite búsquedas, inserciones y eliminaciones en O(log n). Es eficiente para comparaciones de igualdad y rango. No es óptimo para: búsquedas de texto completo (usar GIN con tsvector), datos geoespaciales (usar GiST o SP-GiST), columnas con muy baja cardinalidad donde un bitmap scan es más eficiente, o arrays y JSONB donde los índices GIN permiten buscar dentro de los valores.
Streaming replication con WAL shipping a una o más réplicas standby. Para failover automático, Patroni es el estándar actual: gestiona el consenso entre nodos usando etcd o ZooKeeper, promueve automáticamente la réplica más actualizada al fallar el primario, y actualiza el endpoint de conexión vía HAProxy o un registro en el service discovery. La aplicación conecta a un endpoint virtual que siempre apunta al primario actual, sin cambios de configuración durante el failover.
Multi-Version Concurrency Control permite que los lectores y escritores no se bloqueen mutuamente: cada transacción ve una snapshot consistente de los datos en el momento en que inició. El costo es que las versiones antiguas de las filas (dead tuples) se acumulan hasta que VACUUM las limpia. Sin VACUUM suficiente, el table bloat degrada el rendimiento y puede causar transaction ID wraparound, un problema crítico. Monitorear el lag de VACUUM y el dead tuple ratio es parte del mantenimiento rutinario.
Particionamiento por rango de fecha (monthly o weekly partitions) es el más adecuado para datos de series de tiempo. Permite: eliminar particiones antiguas con DROP PARTITION en lugar de DELETE (instantáneo y sin bloat), confinar las queries recientes a particiones pequeñas mejorando el rendimiento, y aplicar políticas de retención de datos limpias. Crear las particiones futuras con anticipación. Verificar que las queries incluyan la columna de partición en el WHERE para que el planner haga partition pruning.
Confirmar el bloat con pg_relation_size vs. pg_total_relation_size o la extensión pgstattuple. Causas frecuentes: VACUUM autovacuum deshabilitado o con configuración demasiado conservadora, transacciones de larga duración que impiden que VACUUM limpie dead tuples. Solución sin downtime: VACUUM FULL requiere lock exclusivo (no apto para producción activa); usar pg_repack o pgcompacttable para reorganizar la tabla online. Ajustar los parámetros de autovacuum (autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay) para que sea más agresivo en tablas con alta rotación.
Separar la carga OLAP de la OLTP añadiendo réplicas de lectura dedicadas para queries analíticas. Dirigir las queries de reporting a las réplicas via connection pooling (PgBouncer) o a nivel de aplicación. Para queries muy pesadas, evaluar materializar los resultados en tablas de agregación actualizadas periódicamente. Si la carga analítica crece indefinidamente, considerar mover el workload a un sistema OLAP dedicado (Redshift, BigQuery, ClickHouse) con sincronización desde la BD transaccional.
Usar triggers de auditoría solo en tablas con datos sensibles, no en toda la BD. Escribir los registros de auditoría de forma asíncrona a una tabla separada o a un sistema externo (Kafka, log centralizado) para no añadir latencia al path de escritura. En PostgreSQL, pgaudit permite auditoría granular por objeto y tipo de operación con menor overhead que triggers personalizados. Para cumplimiento estricto, enviar los logs de auditoría a un sistema inmutable externo donde no puedan ser alterados.
PostgreSQL crea un proceso por conexión, con un costo de memoria significativo (5-10MB por conexión). Con cientos de instancias de la aplicación, las conexiones directas saturan la BD. PgBouncer mantiene un pool pequeño de conexiones reales a la BD y multiplexa muchas conexiones de la aplicación sobre ellas. En modo transaction pooling, la conexión se devuelve al pool al finalizar cada transacción. El trade-off: algunas features de PostgreSQL que dependen de estado de sesión (prepared statements, advisory locks, SET LOCAL) no funcionan correctamente en transaction pooling.

Preguntas avanzadas

Evaluar entre replicación activa-pasiva (una región primaria, réplicas de lectura en otras regiones) y activa-activa (escrituras en múltiples regiones con resolución de conflictos). Activa-pasiva es más simple y evita conflictos de escritura; el costo es latencia de escritura para usuarios lejanos al primario. Activa-activa con CRDTs o resolución basada en timestamp es viable solo para modelos de datos que toleran conflictos. CockroachDB o Spanner son opciones para consistencia global sin gestionar la complejidad manualmente.
Identificar los bounded contexts y sus datos asociados. Comenzar con los dominios más independientes. La estrategia estándar es el patrón strangler fig: el nuevo servicio escribe en su propia BD y en la monolítica en paralelo durante la transición. Una vez que el nuevo sistema es estable, la escritura en el monolito se desactiva y el monolito pasa a leer del nuevo servicio vía API. El mayor riesgo es la consistencia entre dominios: las transacciones distribuidas deben reemplazarse con eventual consistency y eventos de dominio.
Primero contener: deshabilitar los procesos que continúan escribiendo datos corruptos. Luego evaluar el alcance exacto con queries de diagnóstico. Restaurar desde el backup más reciente antes de la corrupción usando PITR si está disponible. Si la restauración completa no es viable, identificar los registros afectados y corregirlos con scripts validados en staging primero. Documentar el incidente completo: causa raíz, alcance, acciones tomadas y mejoras para prevenir recurrencia. La comunicación con stakeholders debe ser honesta sobre el alcance real del impacto.
La migración se justifica cuando el modelo relacional es un obstáculo real y medible: esquemas que cambian muy frecuentemente y generan migraciones costosas, datos con estructura altamente variable entre registros, patrones de acceso que requieren escala horizontal masiva que PostgreSQL no puede alcanzar. No migrar por moda tecnológica. En la mayoría de los casos, PostgreSQL con JSONB para los campos variables y particionamiento para el volumen resuelve el problema sin el costo de migrar. Si la migración se justifica, hacerla incremental por entidad de negocio, no como big bang.
Integrar la revisión en el pipeline: herramientas como Squawk o sqlfluff detectan automáticamente migraciones peligrosas (ALTER TABLE que genera lock exclusivo, añadir columna NOT NULL sin default en tabla grande). El DBA revisa solo los cambios que las herramientas automáticas marcan como de alto riesgo. Proporcionar a los desarrolladores una guía de patrones seguros de migración con ejemplos. El objetivo es que el 80% de las migraciones pasen sin revisión manual gracias a que el equipo conoce los patrones correctos.
Clasificar los datos por categoría: datos operacionales activos, datos históricos requeridos por compliance, y datos sujetos a right-to-be-forgotten. Implementar particionamiento por fecha para facilitar el archivado y eliminación de datos antiguos. Los datos que deben conservarse por compliance se mueven a almacenamiento más barato (S3 Glacier) con metadatos que permitan recuperarlos si se requiere. Los datos sujetos a eliminación deben tener un mecanismo de borrado verificable que incluya backups. Documentar el flujo completo para auditorías de compliance.

Errores comunes en entrevistas

Los índices no son siempre la solución correcta y tienen costos reales en escrituras y mantenimiento. Un DBA que propone añadir un índice sin haber ejecutado EXPLAIN ANALYZE y entendido por qué el planner no usa los índices existentes demuestra un diagnóstico superficial que puede empeorar el problema.
Cualquier cambio en una base de datos de producción debe tener un procedimiento de rollback probado antes de ejecutarse. Un DBA que describe migraciones sin mencionar cómo se revierte si algo falla genera desconfianza inmediata en entrevistadores con experiencia en incidentes reales de base de datos.
Los backups resuelven pérdida de datos (RPO). La alta disponibilidad resuelve tiempo de inactividad (RTO). Son complementarios, no sustitutos. Un sistema con backups excelentes pero sin HA puede tener horas de downtime para restaurar. Un sistema con HA pero sin backups puede perder datos ante corrupción o borrado accidental.
Un backup que nunca se ha restaurado es una hipótesis, no una garantía. Los entrevistadores de empresas con datos críticos preguntan específicamente cuándo fue la última vez que se probó la restauración y cuánto tardó. No tener respuesta a esa pregunta es una señal de alerta operacional grave.
Un esquema no es bueno o malo en abstracto; es bueno o malo para un conjunto de patrones de acceso. Describir un diseño de base de datos sin explicar qué queries se optimizó, qué volumen de escrituras se anticipó o qué relaciones se privilegió demuestra que el diseño fue intuitivo y no basado en evidencia.
Operaciones como ADD COLUMN NOT NULL sin default, CREATE INDEX sin CONCURRENTLY, o VACUUM FULL adquieren locks exclusivos que bloquean lecturas y escrituras. Un DBA que propone estos cambios sin mencionar el impacto en la disponibilidad o cómo evitarlo con variantes online demuestra falta de experiencia con bases de datos de producción bajo carga real.