Datos e Infraestructura · 2026

CV Harvard para Administradores/as de Bases de Datos

Tu CV es un plan de ejecución: muestra uptime, recuperación y rendimiento medibles, no una lista de versiones de motores.

Empezar mi CVgratis · sin login
Harvard Resume··~5 min

¿Cómo se hace un CV de Administradores/as de Bases de Datos en formato Harvard?

A los Administradores de Bases de Datos los contratan equipos de plataforma, datos y SRE que escanean tu CV buscando primero el radio de impacto y la confiabilidad: nueves de uptime, RPO/RTO del lado de la recuperación, lag de replicación y cuánta latencia de queries o costo de almacenamiento lograste recortar. El formato Harvard de una página te obliga a pasar de un muro de logos de motores (Oracle, PostgreSQL, SQL Server, MySQL) a resultados concretos — queries más rápidas, backups recuperables, migraciones sin downtime — medidos en milisegundos, nueves y dólares. Empieza con trabajo de confiabilidad y tuning cuantificado, mantén educación y certificaciones compactas, y que cada bullet se lea como un plan de ejecución bien optimizado.

Qué buscan los recruiters

  • Disponibilidad cuantificada: nueves de uptime (99,99%), tiempo de failover, lag de replicación bajo el objetivo (ej. < 1s) y RPO/RTO realmente probados en simulacros de DR
  • Profundidad en tuning de rendimiento: latencia p95/p99 de queries reducida, estrategia de índices, particionamiento, análisis de planes de ejecución y wait stats (no solo 'optimicé queries')
  • Rigor en backup y recuperación: estrategia de respaldo, recuperación point-in-time (PITR), restores probados y el tiempo de recuperación logrado en un incidente real
  • Alcance real de migraciones: upgrades de versión, lift-and-shift a la nube (RDS/Aurora/Cloud SQL/Azure SQL), cambios de esquema a escala, con cifras de downtime y volumen de datos
  • Arquitectura HA/DR nombrada explícitamente: Always On AG, Oracle Data Guard/RAC, replicación streaming de PostgreSQL, Patroni, réplicas de lectura, sharding
  • Certificaciones que habilitan el rol: Oracle OCP, Microsoft Azure Database Administrator Associate (DP-300), AWS Database Specialty, MongoDB DBA, certificaciones de PostgreSQL

Secciones requeridas, en este orden

Empieza por confiabilidad y rendimiento, no por una lista de motores

  • Pon una sección de Experiencia compacta justo después de Educación; abre cada bullet con el resultado de confiabilidad o rendimiento (uptime, latencia p99, RPO/RTO, $ ahorrado), no con el nombre del motor
  • Limita el bloque de 'Habilidades Técnicas' al pie — agrupa por Motores / HA-DR / Cloud / Herramientas para que el ATS haga match sin una sopa de 30 ítems
  • Indica la escala de datos dentro del bullet, no en una línea de skills: 'clúster OLTP de 12 TB, 40K transacciones/seg en peak' le muestra al revisor tu radio de impacto al instante
  • Elimina herramientas de hobby y entradas en plan 'familiarizado con' — lista solo motores que te despertarían a las 3am a arreglar y te podrían interrogar en una entrevista

Que Educación y certificaciones jueguen al estilo Harvard

  • Educación primero, una línea cada una: título, institución, año de egreso — sin promedio salvo que sea alto y hayas egresado hace poco
  • Pon las certificaciones vigentes y demandadas (OCP, DP-300, AWS Database Specialty) justo bajo Educación, con el organismo emisor y el año
  • Saca certificaciones vencidas o deprecadas; un OCP de Oracle 11g o un MCITP de SQL Server 2008 señalan ops desactualizada, no profundidad
  • Si eres autodidacta o cambias de carrera, lidera con bases de datos que pusiste en producción y wins de recuperación — el formato Harvard premia resultados sobre pedigrí

Una página, limpio para ATS, disciplina de texto plano

  • Sin foto, sin fecha de nacimiento, sin gráficos ni barras de habilidad — los optimizadores de queries no tienen barras de progreso y tu CV tampoco
  • Una sola columna, fuentes estándar, sin tablas ni cuadros de texto — muchos parsers ATS destrozan los CV de infra a dos columnas y devuelven basura
  • Escribe la herramienta y su sigla una vez: 'Alta Disponibilidad (HA) con Always On Availability Groups' para que hagan match ambas variantes
  • Orden cronológico inverso, bullets con verbo de acción (Optimicé, Migré, Automaticé, Recuperé) — cada línea se gana su lugar o se elimina

Ejemplo en formato Harvard

CV Harvard Administrador de Bases de Datos · 2026
Harvard format · 1 página

Bullets fuertes vs débiles

Antes

Optimicé queries lentas y mejoré el rendimiento de la base de datos.

Después

Bajé la latencia p99 de queries de 1,8s a 240ms en un clúster OLTP de SQL Server de 12 TB rediseñando la estrategia de índices, eliminando 14 missing-index scans y reescribiendo 6 stored procedures críticos — sosteniendo 40K transacciones/seg en peak sin downtime de esquema.

Nombra el motor, la escala de datos (12 TB), la métrica antes/después (latencia p99), las palancas exactas (índices, stored procs) y el throughput. El revisor entiende en segundos que hay tuning de nivel producción.

Antes

Responsable de los backups y la recuperación ante desastres.

Después

Reconstruí la estrategia de backup y DR sobre 30 instancias PostgreSQL, implementando recuperación point-in-time basada en WAL y simulacros de restore trimestrales que bajaron el RTO de 6 horas a 22 minutos y probaron un RPO < 5 minutos — recuperando una base de 4 TB corrupta durante un Sev-1 real con cero pérdida de datos.

Convierte una tarea difusa en números RPO/RTO probados, el mecanismo exacto (PITR con WAL), la cadencia (simulacros trimestrales) y un resultado de incidente real (cero pérdida de datos). Esto es rigor de recuperación, no un checkbox.

Antes

Ayudé a migrar bases de datos a la nube.

Después

Lideré una migración casi sin downtime de 18 bases de datos productivas (9 TB) de Oracle on-prem a AWS Aurora PostgreSQL usando DMS y replicación lógica, bajando el costo de licencias e infraestructura un 41% (USD 380K/año) y conteniendo el cutover a 90 segundos vía switch de tráfico a réplica de lectura.

Alcance de la migración (18 BDs, 9 TB), el tooling (DMS, replicación lógica), el resultado en dólares y el mecanismo de seguridad (cutover de 90 segundos, switch a réplica). Disciplina de migración de nivel producción en una línea.

Antes

Configuré replicación y alta disponibilidad para la base de datos.

Después

Diseñé una topología HA multi-región con Always On Availability Groups de SQL Server en 3 data centers, manteniendo el lag de replicación bajo 800ms y automatizando el failover que subió el uptime de 99,9% a 99,99% — reduciendo a cero el downtime de mantenimiento planificado con parchado rolling de secundarios.

Nombra la tecnología HA (Always On AG), la escala de la topología (3 data centers), el objetivo de lag, los nueves de uptime antes/después y el win operativo (parchado sin downtime). Se lee como un postmortem de disponibilidad con final feliz.

Errores comunes específicos

  • Listar todos los motores y versiones que tocaste como un muro plano de keywords. Los reclutadores confían en la profundidad sobre la amplitud — agrupa 4-6 categorías y lista solo bases de datos sobre las que te puedan interrogar.
  • Describir tareas en vez de resultados ('responsable de los backups'). Cada bullet necesita un número: nueves de uptime, latencia p99, minutos de RTO, lag de replicación o dólares ahorrados.
  • Ocultar la escala de datos y tráfico. 'Gestioné bases de datos' no dice nada; 'clúster OLTP de 12 TB, 40K TPS en peak, 30 instancias' le muestra al revisor tu radio de impacto real.
  • Mantener certificaciones vencidas o deprecadas (OCP de Oracle 11g, MCITP de SQL Server 2008). Señalan que dejaste de aprender — sácalas y destaca las vigentes que habilitan el rol.
  • Irte a dos páginas con detalle de tareas junior. La disciplina Harvard es una página — si un bullet no tiene métrica ni escala, es relleno, elimínalo.

Tu CV empieza aquí. Decides después si pagas.

Empezar mi CV

Preguntas frecuentes

¿Debo listar todos los motores de bases de datos que toqué, o solo los más fuertes?
Solo los más fuertes. Un muro plano de 20 motores y versiones se lee como superficial y ensucia el match del ATS. Agrupa 4-6 categorías (Relacionales, NoSQL, Cloud-managed, HA/DR, Herramientas) y lista solo motores que puedas defender en una entrevista de tuning de queries o recuperación. La profundidad gana: un stack Oracle/PostgreSQL/SQL Server que de verdad dominas supera a una sopa de logos.
¿Cómo cuantifico el trabajo de DBA si no 'lanzo features'?
Tus métricas son confiabilidad y rendimiento, no features. Cuantifica uptime (nueves), RTO/RPO (minutos), lag de replicación (ms), latencia p95/p99 de queries reducida, tasa de éxito de restores, costo de almacenamiento o licencias recortado ($ y %) y transacciones/seg en peak. Esto es exactamente lo que los hiring managers de plataforma, datos y SRE escanean primero.
¿Necesito certificaciones como Oracle OCP o Azure DP-300?
No son obligatorias pero habilitan muchos roles y filtros de ATS — OCP para shops de Oracle, DP-300 (Azure Database Administrator Associate) para stacks Microsoft, AWS Database Specialty para equipos con mucha nube. Pon las certificaciones vigentes bajo Educación con emisor y año. Saca las caducadas o deprecadas; una cert vencida señala skills desactualizadas, no credibilidad.
¿Cómo muestro experiencia de DBA en la nube frente a DBA on-prem tradicional?
Nombra el servicio gestionado explícitamente (RDS, Aurora, Cloud SQL, Azure SQL Database) y cuantifica lo que cambió: costo recortado al salir de motores con licencia, downtime durante la migración, failover automatizado o almacenamiento escalado bajo demanda. A los DBA cloud se les juzga tanto por ingeniería de costos y disciplina de migración como por tuning, así que haz visibles esos resultados junto a cualquier trabajo de HA/DR on-prem.

Recursos relacionados