En resumen PostgreSQL no viene con un conjunto de monitoreo integrado, un administrador de copias de seguridad o un marco de alta disponibilidad; tú mismo armas la pila con herramientas especializadas.
Eso no es una debilidad: significa que eliges lo que se adapta a tu entorno en lugar de pagar por funciones que no utilizas.
Esta lista cubre una mejor opción en su clase por categoría, con notas breves sobre cuándo usar las alternativas.
Hay seis categorías que son innegociables en la producción: alta disponibilidad/conmutación por error, copias de seguridad y recuperación puntual, agrupación de conexiones, monitorización, análisis de consultas y análisis de registros.
Todo lo demás es opcional.
He configurado PostgreSQL en entornos de producción que vinieron después de Oracle RAC, después de SQL Server AlwaysOn y después de MySQL básico sin alta disponibilidad en absoluto.
La pregunta que más me hacen es la misma: ¿qué herramientas realmente necesito?
Oracle viene con todo incorporado: RMAN para copias de seguridad, Enterprise Manager para supervisión, Data Guard para copias de seguridad, DBMS_SCHEDULER para trabajos.
PostgreSQL no lo hace.
Construyes la pila a partir de componentes, y cada componente hace bien una cosa.
Estas son las herramientas que instalo o recomiendo en cada despliegue de producción de PostgreSQL.
Índice
¿Qué herramientas necesita para ejecutar PostgreSQL en producción?
Seis categorías son innegociables: alta disponibilidad y conmutación por error, copias de seguridad con recuperación a un punto en el tiempo, agrupación de conexiones, monitorización, análisis de consultas y análisis de registros.
Si te saltas alguna de las cuatro primeras, tendrás un hueco que te costará en producción.
Todo en las secciones a continuación se asigna a uno de estos seis, con una recomendación principal por categoría y notas claras sobre cuándo las alternativas tienen más sentido.
Alta Disponibilidad — Patroni
Patroni es el estándar para alta disponibilidad de PostgreSQL en entornos locales y en la nube.
Gestiona un clúster de nodos PostgreSQL, maneja la elección del líder a través de un almacén de configuración distribuido externo (etcd, Consul o ZooKeeper) y realiza failover automático cuando el nodo principal falla.
Los cambios son manuales y limpios — útiles para el mantenimiento planificado.
La API REST te permite consultar el estado del clúster, activar cambios de rol y integrarte con balanceadores de carga externos.
Para la mayoría de las implementaciones locales, Patroni con etcd es la opción correcta.
La comunidad es grande, la documentación es exhaustiva y maneja los casos extremos que las herramientas más simples pasan por alto.
¿Cuándo usar las alternativas?
repmgr — más simple de configurar, menor sobrecarga operativa; bueno para entornos más pequeños donde la pila completa de Patroni/etcd es más de lo necesario.
pg_auto_failover — extensión única, sin dependencias externas; el camino más fácil para la conmutación automática por error para equipos que desean algo que funcione sin administrar etcd.
Estolón — diseñado para Kubernetes; úselo cuando el cliente esté ejecutando PostgreSQL en Kubernetes y quiera una integración nativa.
Si migras desde Oracle RAC, Patroni es el equivalente funcional más cercano para la conmutación por error automática.
No es activo-activo — PostgreSQL + Patroni es un modelo primario/en espera con promoción automática.
Para cargas de trabajo que realmente requerían la escritura/lectura activa-activa de RAC a través de nodos, esa es una diferencia arquitectónica real que vale la pena evaluar por separado.
Copia de seguridad y recuperación en un momento dado — pgBackRest
pgBackRest es la primera herramienta que instalo en cada servidor PostgreSQL.
Maneja copias de seguridad completas, diferenciales e incrementales; copias de seguridad y restauración paralelas; archivo de WAL y recuperación a un punto en el tiempo.
Comprime y opcionalmente cifra los archivos de copia de seguridad, admite almacenamiento local y remoto, y tiene una documentación clara y bien mantenida.
Para los DBAs de Oracle, este es el equivalente en RMAN.
PITR funciona reproduciendo segmentos de WAL a partir de una copia de seguridad base, lo que le permite recuperarse hasta cualquier punto en el tiempo entre copias de seguridad, el mismo modelo que la recuperación basada en SCN de Oracle, expresado de manera diferente.
¿Cuándo usar las alternativas?
WAL-G — mejor para entornos nativos de la nube donde las copias de seguridad llegan a S3, GCS o Azure Blob Storage; más ligero que pgBackRest, sin archivo de configuración.
Barman — opción sólida para entornos de múltiples servidores administrados centralmente; ampliamente utilizada en empresas que desean un modelo de servidor de respaldo dedicado.
No utilice WAL-E para nuevas implementaciones; ha sido reemplazado por WAL-G por el mismo autor.
La única regla que importa por encima de todo: prueba tus restauraciones.
Una copia de seguridad que nunca has restaurado no es una copia de seguridad, es un archivo.
Programa una restauración mensual a un servidor separado y verifica los datos.
Agrupación de Conexiones — PgBouncer
PgBouncer no es opcional en producción.
PostgreSQL crea un nuevo proceso del sistema operativo por cada conexión de cliente.
A bajas cantidades de conexión esto está bien.
A las 500 conexiones concurrentes se convierte en un problema de rendimiento.
A las 2.000 se cae el servidor.
PgBouncer se sitúa entre la aplicación y PostgreSQL y multiplexa muchas conexiones de cliente para un pequeño grupo de conexiones de servidor.
Para aplicaciones que migran desde Oracle —donde el modelo de servidor compartido de Oracle o la agrupación de conexiones a través de UCP o JDBC lo manejaban de forma transparente—, añadir PgBouncer es un paso de migración obligatorio, no una optimización opcional.
La elección de configuración que más importa es el modo de agrupación:
Modo de transacción — una conexión de servidor se mantiene solo durante la duración de una transacción; máxima eficiencia; interrumpe aplicaciones que utilizan funciones a nivel de sesión (sentencias preparadas, bloqueos consultivos, SET LOCAL).
Modo de sesión — una conexión de servidor por sesión de cliente; menor eficiencia; compatible con todo; usa esto si el modo de transacción causa errores en la aplicación.
Comience en modo de transacción y cambie secciones de tráfico a modo de sesión solo donde sea necesario.
pgpool-II es la alternativa — añade equilibrio de carga de consultas de lectura sobre el agrupamiento.
Úselo solo cuando necesite esa funcionalidad específica; agrega una complejidad operativa significativa en comparación con PgBouncer.
Monitoreo — postgres_exporter y pgwatch2
Ninguna herramienta única cubre todas las configuraciones de monitoreo, así que doy dos recomendaciones según lo que el cliente ya tenga.
postgres_exporter — si el cliente ejecuta Prometheus y Grafana, este es el estándar.
Expone métricas de PostgreSQL en formato Prometheus, se integra con dashboards existentes y tiene plantillas de dashboards de Grafana mantenidas por la comunidad listas para importar.
pgwatch2 — si el cliente no tiene Prometheus y desea una pila de monitoreo autónoma, pgwatch2 viene con su propio almacenamiento (TimescaleDB o PostgreSQL) y paneles de Grafana preconstruidos.
Menor fricción en la configuración que al construir la pila de Prometheus desde cero.
Qué monitorear sin importar la herramienta que utilices:
Conexiones activas vs. max_connections.
Latencia de replicación en réplicas en espera.
Esperas de bloqueo y interbloqueos.
Actividad de Autovacuum y hinchazón de tablas.
Consultas de larga duración.
Relación de aciertos de caché.
PMM (Percona Monitoring and Management) es la opción de pila completa —monitoreo, análisis de consultas y alertas en un solo paquete.
Recomiéndalo a clientes que quieren todo preconfigurado y no tienen infraestructura de Prometheus existente.
¿Ejecutando PostgreSQL en producción por primera vez después de una migración de Oracle?
Ofrezco una revisión de salud integral con tarifa fija que cubre la configuración de HA, la verificación de copias de seguridad, el pooling de conexiones y la monitorización, entregada como un informe escrito con hallazgos.
Ver lo que cubre la revisión de salud →
Análisis de Consultas — pgBadger y PEV2
pgBadger es la primera herramienta que ejecuto cuando investigo quejas de consultas lentas después de una migración.
Analiza archivos de registro de PostgreSQL y genera un informe HTML que muestra las consultas más lentas, las consultas más frecuentes, esperas de bloqueo, actividad de conexión y patrones de error.
Habilitar log_min_duration_statement en postgresql.conf para capturar consultas lentas, luego ejecutar pgBadger contra los registros.
El informe ofrece una imagen clara de a dónde se va el tiempo de consulta en cuestión de minutos.
PEV2 (Postgres EXPLAIN Visualizer 2) es una herramienta en línea que toma la salida de EXPLICAR (ANALIZAR, BUFERS) y lo representa como un diagrama de planos anotado y codificado por colores.
Hace que los planes de consulta sean legibles para desarrolladores y clientes que aún no piensan en términos de planes de ejecución de PostgreSQL.
Útil para mostrar a los clientes exactamente dónde una consulta está perdiendo tiempo y por qué un cambio de índice ayuda.
HipopG es una extensión de PostgreSQL que vale la pena conocer para la optimización del rendimiento posterior a la migración.
Te permite crear índices hipotéticos —índices que solo existen en la vista del planificador— y ejecutar EXPLICAR contra ellos para probar si un nuevo índice ayudaría antes de asumir el costo de crearlo en una tabla grande.
Esto es particularmente útil durante los primeros 30 a 90 días posteriores a la migración, cuando el rendimiento de las consultas se está ajustando a cargas de trabajo de producción reales.
Extensiones que todo DBA de producción debería conocer
Estas seis extensiones cubren las carencias más comunes que los DBA de Oracle notan después de la migración.
| Extensión | Reemplaza o cubre |
|---|---|
| pg_partman | Automatiza el mantenimiento de particiones: crea, desacopla y elimina particiones según lo programado; reemplaza la gestión manual de la partición por intervalos de Oracle |
| PGAudit | Registro de auditoría detallado a nivel de sesión y objeto; el equivalente más cercano a Oracle Unified Auditing; requerido para cargas de trabajo de cumplimiento |
| pg_cron | Ejecuta trabajos programados dentro de PostgreSQL utilizando sintaxis cron; reemplaza Oracle DBMS_SCHEDULER para tareas recurrentes sencillas |
| pglogical | Replicación lógica entre instancias PostgreSQL; la base para estrategias de migración con tiempo de inactividad cero |
| pg_stat_monitor | Mejora instantánea en pg_stat_statements; agrega histogramas, captura de planes de consulta e información del cliente |
| plpgsql_check | Análisis estático para código PL/pgSQL; ejecútelo contra procedimientos almacenados de Oracle convertidos antes del despliegue para detectar errores que solo aparecen en tiempo de ejecución. |
GUI y CLI — DBeaver y pgcli
DBeaver es la herramienta que recomiendo a cualquier DBA que esté migrando de Oracle a PostgreSQL y necesite trabajar con ambas bases de datos simultáneamente durante la migración.
Es gratuito, de código abierto y admite Oracle, PostgreSQL, MySQL, SQL Server y la mayoría de las otras bases de datos desde una única interfaz.
Durante una migración, a menudo comparas datos entre Oracle y PostgreSQL en tiempo real — DBeaver maneja esto sin cambiar de herramienta.
pgcli es el reemplazo de línea de comandos para psql.
Agrega autocompletado para nombres de tablas, nombres de columnas y palabras clave de SQL, resaltado de sintaxis y salida formateada.
Para los DBA de Oracle acostumbrados a SQL*Plus con un buen prompt, pgcli elimina la mayor parte de la fricción de las primeras semanas en la línea de comandos.
Para los equipos de clientes post-migración: pgAdmin es la GUI gratuita estándar y la mayoría de los equipos ya la conocen.
DataGrip (JetBrains) es la opción preferida para equipos con muchos desarrolladores: funciones completas de IDE, excelente editor de consultas, comparación de esquemas.
Una Herramienta Que La Mayoría de Los DBA Pasan Por Alto — postgres-checkup
postgres-checkup ejecuta un análisis de salud estructurado de una instancia PostgreSQL y genera un informe detallado en Markdown que cubre hinchazón, índices faltantes, riesgo de ranura de replicación, problemas de autovacuum, problemas de configuración y más.
Lo ejecuto al inicio de cada compromiso de chequeo de salud y al final de cada migración antes de la aprobación.
Saca a la luz problemas que de otro modo solo serían visibles bajo carga de producción: tablas con hinchazón significativa, índices que no se han utilizado en meses, ranuras de replicación que retienen WAL y podrían llenar el disco.
Se tarda menos de diez minutos en ejecutarse y produce un informe que se puede entregar directamente a un cliente.
Preguntas frecuentes
¿Cuál es la mejor herramienta de monitoreo para PostgreSQL?
Para los equipos que ejecutan Prometheus y Grafana, el exportador de postgres con un panel preconstruido es el estándar.
Para equipos que desean una pila de monitoreo autocontenida sin construir una infraestructura de Prometheus, pgwatch2 incluye almacenamiento y paneles integrados.
Para los equipos que quieren todo preenpaquetado, Percona Monitoring and Management (PMM) es la opción de pila completa.
¿Necesito PgBouncer si mi aplicación ya utiliza un pool de conexiones?
Sí, en la mayoría de los casos.
Las agrupaciones de conexiones a nivel de aplicación reducen el número de conexiones de un servicio de aplicación, pero en arquitecturas multiserVICIO, cada servicio mantiene su propia agrupación.
El recuento total de conexiones del lado del servidor sigue creciendo con el número de servicios e instancias.
PgBouncer se sienta a nivel de base de datos y limita el total independientemente de cuántos grupos de aplicaciones existan aguas arriba.
pg_basebackup
pgBackRest es el equivalente más cercano: maneja copias de seguridad completas, incrementales y diferenciales, archivo de WAL y recuperación puntual.
Para entornos en la nube, WAL-G es una alternativa más ligera que archiva WAL y copias de seguridad directamente en S3, GCS o Azure Blob Storage.
Ambos admiten PITR, que es el equivalente de PostgreSQL de la recuperación basada en SCN de Oracle.
¿Qué reemplaza a Oracle Enterprise Manager en PostgreSQL?
No hay un equivalente único: la monitorización de PostgreSQL se ensambla a partir de componentes.
postgres_exporter envía métricas a Prometheus y tableros de Grafana; pgBadger analiza los registros de consultas lentas; pgwatch2 proporciona una pila de monitoreo autocontenida.
Para una experiencia integral y más cercana, Percona Monitoring and Management (PMM) cubre métricas, análisis de consultas y alertas en una sola plataforma.
En resumen
Seis categorías, seis herramientas que no puedes saltarte: Patroni para alta disponibilidad, pgBackRest para copias de seguridad y PITR, PgBouncer para gestión de conexiones, postgres_exporter o pgwatch2 para monitorización, pgBadger para análisis de logs, PEV2 para visualización de planes de consulta.
Las extensiones y utilidades de las secciones anteriores cubren las lagunas que los DBA de Oracle notan con más frecuencia en los primeros meses tras la migración.
La pila no es complicada; simplemente está ensamblada de manera diferente a lo que los DBA de Oracle están acostumbrados.
Cada componente hace bien una cosa, y juntos cubren todo lo que RMAN, Enterprise Manager, RAC y DBMS_SCHEDULER proporcionaban en una única licencia de Oracle.
Si estás configurando PostgreSQL en producción por primera vez y deseas una segunda opinión sobre tu pila, ponerse en contacto