Prácticas recomendadas para equipos y incorporación
Un resumen condensado de las 25 prácticas más importantes para equipos y incorporación para organizaciones de PostgreSQL 18.4 - contenido portátil compartido; no solo DDL de producción.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 prácticas más importantes para equipos y incorporación para organizaciones de PostgreSQL 18.4 - contenido portátil compartido; no solo DDL de producción.
Asignar un compañero de base de datos el primer día: DBA del mismo escuadrón o backend senior durante dos semanas como mínimo (Conceptos básicos de incorporación).
Postgres 18.4 local antes que entornos compartidos: Docker compose coincide con la versión principal de producción.
Fluidez en psql antes que herramientas GUI: Scripts \d+, \conninfo, ON_ERROR_STOP.
Hábito de EXPLAIN desde la primera PR: Ninguna revisión de consulta sin (ANALYZE, BUFFERS) en evidencia de staging.
Producción de solo lectura la segunda semana, no el primer día: Reduce el riesgo de accidentes; compañero en las primeras cinco sesiones.
No DDL de producción en solitario durante los primeros 90 días: Migraciones fusionadas con revisor de DBA; trabajo en pareja de emergencia.
CONTRIBUTING.md lista las rutas de migración y de guardia: Fuente única para escalaciones.
Seguir la guardia antes de ser el principal: Al menos dos sombras no SEV1 con informe.
Trabajar en pareja en las primeras tres PR de consultas ORM: Trabajo en pareja en PR de consultas previene la cultura N+1.
Matriz de habilidades trimestral con enlaces a evidencia: PR, simulacros, post-mortems - no solo autoevaluación (Matriz de habilidades).
Ruta de desarrollo de aplicaciones → DBA documentada: Las fases evitan omitir HA antes de la profundidad de EXPLAIN (Ruta de desarrollo de aplicaciones → DBA).
Horario de oficina semanal para preguntas de esquema: Reduce los mensajes directos de Slack y el DDL no autorizado.
Consejo de base de datos para esquemas entre equipos: Presidido por personal; ADR para cambios de tablas compartidas.
No migraciones heroicas en despliegues de viernes: Política de ventana de cambio en el acuerdo del equipo.
Actualizaciones de post-mortem de incidentes en la lista de verificación de incorporación: SEV1 se convierte en lectura del día tres del próximo contratado.
Rotar el deber de revisión de manera justa: Distribuir la carga de revisión de migraciones entre los niveles intermedios, no un cuello de botella de un solo DBA.
Celebrar las detecciones seguras: El revisor que bloqueó una omisión CONCURRENTLY recibe reconocimiento - fomenta la cultura.
Documentar quién posee cada esquema: Mapa de servicio a esquema en el repositorio; sin tablas huérfanas.
El nuevo contratado ejecuta el script de paquete de incidentes en staging la primera semana: Demuestra que los scripts de CLI funcionan.
Habilidades de agente introducidas la segunda semana con salvaguardias: Conceptos básicos de habilidades de agente antes de ChatGPT SQL de formato libre.
Ruta de incorporación de análisis separada: Lectura de réplica; SLA de EXPLAIN diferente a OLTP.
La baja de empleados elimina las credenciales de base de datos el mismo día: Auditoría de revocación de roles en el ticket.
Los contratistas obtienen acceso de escritura con tiempo limitado: Fecha de caducidad en los roles de staging.
El bucle de contratación incluye ejercicio de EXPLAIN en vivo: Puntuación alineada con la matriz.
Retrospectiva anual del equipo sobre incidentes de base de datos: Las tendencias impulsan el presupuesto de capacitación.
A menudo, un propietario de base de datos senior para 8-12 ingenieros backend; gobernanza de personal en flotas de múltiples escuadrones. La matriz muestra cuándo contratar.
Misma lista de verificación; añadir sesiones de trabajo en pareja grabadas, revisión asíncrona de EXPLAIN en PR, zona horaria explícita para horarios de oficina.
Sí, con revisión. No deben ser los únicos aprobadores o aplicadores en producción hasta el nivel intermedio de la matriz.
Versiones de la pila: Esta página fue escrita para equipos de plataforma y aplicaciones de PostgreSQL 18.4 que utilizan Flyway y políticas de acceso de producción de solo lectura.
Revisado por Chris St. John·Última actualización: 16 jul 2026