PostgreSQL
PostgreSQL en producción
Operación de PostgreSQL en producción: capacidad, configuración, backups, alta disponibilidad, mantenimiento, observabilidad, cambios y respuesta a incidentes.
- Última actualización
- Actualizada
- Nivel
- Profundización
PostgreSQL
Operación de PostgreSQL en producción: capacidad, configuración, backups, alta disponibilidad, mantenimiento, observabilidad, cambios y respuesta a incidentes.
PostgreSQL en producción es un servicio con SLOs, capacidad, mantenimiento y recuperación. Que acepte conexiones hoy no demuestra que pueda sobrevivir al próximo deploy, pico de tráfico o fallo de región.
La operación se sostiene sobre seis frentes:
confiabilidad
+ rendimiento
+ seguridad
+ cambios
+ recuperación
+ observabilidadTodos necesitan owner, métricas y runbooks.
No adoptes HA compleja sin capacidad de operarla.
Define por operación:
“Base disponible” es demasiado ambiguo: puede aceptar SELECT 1 y aun así no procesar checkout.
Versiona:
Evita cambios manuales sin registro. Comprueba drift y pending_restart.
Orden seguro:
prechecks
→ schema expand
→ app compatible
→ observar
→ backfill
→ validar
→ contract posteriorUsa lock/statement timeout en DDL. No ejecutes migrations pesadas automáticamente desde cada réplica de la app al arrancar.
Presupuesto global de conexiones, acquisition timeout y backpressure. Configura statement/lock/idle transaction timeouts por workload.
Una cola ilimitada convierte una degradación en caída prolongada.
Proyecta:
Observa tendencias y runway, no solo umbrales actuales.
Evita cron de VACUUM FULL o REINDEX sin diagnóstico.
Un job interno puede causar más daño que tráfico externo si no tiene límites.
Define qué lecturas pueden tolerar lag. Monitorea replay, conflictos y capacidad de promoción. Una réplica de reporting debe aislar workload y tener estrategia ante queries largas.
La fecha del último restore exitoso es una métrica de producción.
Dashboard operativo:
Alertas deben tener runbook y severidad basada en impacto.
Incluye seguridad en cada deploy y restore, no como revisión anual aislada.
Flujo:
detectar impacto
→ estabilizar
→ preservar evidencia
→ identificar bottleneck/fallo
→ mitigar reversible
→ validar
→ recuperar redundancia
→ postmortemMitigaciones posibles: cancelar runaway query, terminar blocker confirmado, limitar feature, reducir concurrencia, promover standby, restaurar.
No reinicies antes de entender si perderás evidencia o ampliarás el incidente.
Prueba que:
Mantén major soportada y minor actualizada según política. Prueba extensions, drivers, planes, collations y backups. La nota siguiente desarrolla el proceso.
Constraints, tipos, migrations, retention.
Pool, timeouts, retries, idempotencia, shutdown.
Roles, TLS, secrets, RLS, audit.
Metrics, logs, alerts, runbooks.
Backups, PITR, restore, failover.
Load test, storage runway, replica sizing.
SELECT 1 no demuestra readiness completa?Upgrades, versiones y compatibilidad mantiene el sistema soportado sin tratar una major upgrade como un simple reinicio.