App Dev → DBA Path
Una progresión estructurada de desarrollador de aplicaciones a ingeniero de bases de datos en PostgreSQL 18.4 - índices, MVCC y tu primera revisión de migración con hitos que puedes autoevaluar trimestralmente.
//
Busca en todas las páginas de la documentación
Una progresión estructurada de desarrollador de aplicaciones a ingeniero de bases de datos en PostgreSQL 18.4 - índices, MVCC y tu primera revisión de migración con hitos que puedes autoevaluar trimestralmente.
App Dev → DBA Path (típico 18-36 meses)
Fase 1 (0-6 meses): Fluidez en autor de consultas + EXPLAIN
Fase 2 (6-12 meses): MVCC, bloqueos, migraciones seguras
Fase 3 (12-18 meses): Revisor secundario + simulacro en staging
Fase 4 (18-24 meses): Sombra de guardia + propiedad de HA/PITR
Staff (24+ meses): Gobernanza de flota, RTO/RPO, actualizaciones mayoresCuándo usar esta trayectoria:
-- Aprender la regla del prefijo más a la izquierda del b-tree
CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at DESC);
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders
WHERE tenant_id = $1
ORDER BY created_at DESC
LIMIT 20;Hito: Tres PRs fusionados con evidencia de EXPLAIN aprobados sin solicitudes de reescritura.
-- Ver visibilidad xmin/xmax (conceptual)
SELECT xmin, xmax, ctid FROM orders WHERE id = $1;
-- Modos de bloqueo durante la migración
SELECT mode, granted FROM pg_locks WHERE relation = 'orders'::regclass;Hito: Obtener una migración de riesgo medio correctamente usando la Habilidad de Seguridad de Migraciones antes que el DBA.
Estudio: Arquitectura de PostgreSQL, DDL sin tiempo de inactividad
## Lista de verificación del revisor (tu primera revisión secundaria)
- [ ] Riesgo de bloqueo etiquetado
- [ ] CONCURRENTLY donde sea necesario
- [ ] SQL de reversión presente
- [ ] EXPLAIN si hay cambio de consulta
- [ ] Aprobar o solicitar cambios con comentarios SQL específicosHito: Revisar cinco PRs de migración; cero incidentes en producción rastreados hasta DDL aprobado.
Estudio: Revisión de Código para SQL
# Participación en simulacro de failover
patronictl list
psql -c "SELECT pg_is_in_recovery();"Hito: Liderar el rol de escriba en un simulacro de failover en staging; documentar RTO en un ticket.
Estudio: Habilidad de Simulacro de Failover, Conceptos básicos de PITR
| Fortaleza del desarrollador de aplicaciones | Adición de DBA necesaria |
|---|---|
| Modelos ORM | Modos de bloqueo y expansión-contracción de migraciones |
| Ajuste de latencia de API | Caché de búfer y escaneos de solo índice |
| Entrega de características | Ventanas de cambio y disciplina de reversión |
| Pruebas unitarias | Simulacros de restauración y verificación de copias de seguridad |
Semana A: El aprendiz escribe la migración; el mentor revisa con la rúbrica de la Habilidad de Revisión de EXPLAIN
Semana B: El aprendiz revisa el PR de un compañero de equipo de aplicaciones; el mentor audita la calidad de la revisión
Semana C: Paquete de incidentes conjunto en alerta simulada en staging| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| Contratar DBA externo | Industria regulada, flota grande | Sensible al costo al inicio de la startup |
| Permanecer especialista en aplicaciones | Existe un sólido equipo de DBA de plataforma | El equipo tiene cero profundidad en Postgres |
| Pista de ingeniero de datos | Enfoque en análisis/ETL | Se necesita propiedad de operaciones OLTP |
Normalmente después de 12-18 meses con trimestres de sombra exitosos y simulacros de failover/PITR aprobados. Depende de la organización.
Útil para el currículum, no sustituye a los simulacros de EXPLAIN + incidentes. La matriz de habilidades interna importa más.
La trayectoria de desarrollo de aplicaciones sobresale en la seguridad de consultas y migraciones; añadir profundidad en Linux/HA en las fases 3-4. Infraestructura pura puede invertir el orden (host primero, SQL segundo).
Versiones de Stack: Esta página fue escrita para equipos OLTP de PostgreSQL 18.4 con migraciones Flyway y HA Patroni o RDS.
Revisado por Chris St. John·Última actualización: 16 jul 2026