Mejores Prácticas para Extensiones

Cómo Usar Esta Lista

• Revísala antes de aprobar cualquier CREATE EXTENSION nuevo en producción.
• Fija versiones en Terraform, Ansible y SQL de migración conjuntamente.
• Revisa trimestralmente contra exportaciones de inventario de pg_extension.

A - Gobernanza

• Mantén un ADR (Documento de Decisión Arquitectónica) escrito de lista blanca. Cada extensión instalada se mapea a un propietario, una versión fija y una fecha de revisión.
• Bloquea extensiones no confiables por defecto. plpython3u, file_fdw y dblink requieren una excepción de CISO.
• Centraliza la autoridad de instalación. Rol dedicado dba_deploy, no contraseñas de superusuario compartidas.
• Registra el DDL de extensiones. Un trigger de eventos o pgaudit captura CREATE EXTENSION con el actor y la base de datos.
• Misma política en staging. Las instalaciones experimentales se desvían hacia restauraciones de copias de seguridad y scripts de migración.

B - Instalación y Diseño

• Usa un esquema extensions dedicado. Mantiene public limpio y clarifica search_path para roles de aplicación.
• Fija la versión en la instalación: CREATE EXTENSION vector WITH SCHEMA extensions VERSION '0.8.0';
• Instala paquetes del sistema operativo antes que SQL. Los archivos de control de extensiones deben existir para tu versión principal de Postgres (18).
• Configura preload antes del reinicio. Añade entradas de shared_preload_libraries solo con una ventana de reinicio planificada.
• Otorga USAGE, no CREATE, a los roles de aplicación. Las aplicaciones llaman a funciones; no instalan extensiones.

C - Actualizaciones y Operaciones

• Actualiza los paquetes en todos los nodos primero. Las réplicas y los standbys de Patroni necesitan binarios .so coincidentes antes de ALTER EXTENSION UPDATE.
• Realiza pruebas de humo después de cada actualización de extensión. Consulta de distancia de PostGIS, consulta de distancia de pgvector, cifrado/descifrado de pgcrypto.
• Planifica la reindexación para cambios en las clases de índice (opclasses). Las notas de lanzamiento de pgvector y PostGIS señalan la necesidad obligatoria de REINDEX.
• Recorre todas las bases de datos. template1, postgres y las bases de datos de análisis son fáciles de pasar por alto.
• Archiva el inventario trimestralmente. SELECT * FROM pg_extension por base de datos almacenado con los IDs de los tickets de cambio.

D - Seguridad y Cumplimiento

• Revoca el permiso PUBLIC de ejecución en funciones sensibles. La instalación de extensiones no implica que sean llamables en toda la aplicación.
• Mantén las extensiones fuera de los roles de DDL de replicación lógica. Los suscriptores deben coincidir con las versiones antes de la reproducción.
• Escanea en busca de CVEs en las versiones fijadas. pgvector, PostGIS y pgcrypto tienen ciclos de lanzamiento independientes del núcleo de Postgres.
• Documenta las implicaciones de la licencia. La GPL de PostGIS puede ser relevante para el empaquetado de SaaS; regístralo en el ADR.
• Valida los runbooks de restauración. La restauración PITR vuelve a aplicar el conjunto de extensiones antiguo; ejecuta el hook de inventario post-restauración.

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Extensiones - CREATE EXTENSION y preload
• Política de Lista Blanca de Extensiones - ADR empresarial
• Ruta de Actualización de Extensiones - ALTER EXTENSION UPDATE
• Extensiones Confiables vs. No Confiables - revisión de seguridad
• Conceptos Básicos de Postgres Gestionado - matrices de extensiones en la nube

Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PostGIS 3.5+, pgbouncer 1.x, y Patroni 3.x.