PostgreSQL gestionado en vuestra cuenta: réplicas, copias y PITR probados

Con pgBackRest o WAL-G hacemos copias base periódicas y archivamos cada segmento de WAL en un almacenamiento de objetos de otra cuenta o de otro proveedor, cifrado. Una vez al mes, como mínimo, restauramos en un servidor de prueba a un momento concreto, comprobamos que la base de datos arranca y lanzamos unas consultas de control. El tiempo que tarda es vuestro tiempo real de recuperación, y lo apuntamos en el informe para que no sea una estimación.

Hay dos caminos. Con pg_upgrade la actualización se hace en el mismo servidor y el corte es corto, sobre todo con enlaces de archivos. Con replicación lógica preparamos un servidor nuevo con la versión nueva, lo mantenemos sincronizado y cambiamos las aplicaciones cuando ya está probado; tarda más en prepararse pero el corte es mínimo, y es el mismo método que usamos para migrar de RDS o de Cloud SQL a otro sitio. En los dos casos ensayamos antes con una copia y revisamos las extensiones.

Muchas veces sí: cuando existe, la carga es normal y no necesitáis nada especial. RDS, Cloud SQL, Azure Database o las bases de datos gestionadas de DigitalOcean y OVHcloud hacen bien los parches, las réplicas y las copias de bajo nivel. Montamos un PostgreSQL propio cuando el proveedor no lo ofrece, como Hetzner, cuando necesitáis extensiones o parámetros que el servicio no permite, o cuando el coste del gestionado se dispara con el tamaño. Aun así hay trabajo: parámetros, índices, consultas lentas, alertas y pruebas de restauración. Si queréis que esa vigilancia sea continua, encaja en el SRE como servicio; y las métricas acaban en la monitorización con Grafana y Prometheus.

TimescaleDB no es otra base de datos: es una extensión de PostgreSQL para series temporales, como lecturas de sensores, métricas o precios. Convierte las tablas grandes en hipertablas partidas por tiempo, comprime los datos antiguos y borra lo que caduca con políticas de retención. Lo que sabéis de PostgreSQL sigue valiendo, y lo gestionamos igual: réplica, copias con pgBackRest y restauración probada.

Hay dos detalles propios. La compresión, los agregados continuos y las políticas de retención van con la Timescale License, no con Apache 2.0: podéis usarlas en vuestra cuenta, pero muchas bases de datos gestionadas de los proveedores no ofrecen la extensión o solo traen la parte Apache, así que normalmente la montamos en un PostgreSQL propio. Y en cada actualización mayor comprobamos antes que la versión de la extensión es compatible con la versión de PostgreSQL de destino, y la actualizamos primero.