¿Puede Immich usar una base de datos externa sin complicar las actualizaciones?

Immich puede conectarse a un servicio PostgreSQL externo, pero eso no hace que las actualizaciones sean seguras automáticamente; traslada fuera de la pila predeterminada la responsabilidad de la versión de la base de datos, las extensiones, los privilegios, las copias de seguridad y la reversión.

Considera una base de datos externa como un límite de compatibilidad avanzado, no como una simple opción de rendimiento. Antes de cada actualización de Immich o PostgreSQL, verifica los requisitos de la versión exacta de Immich que planeas ejecutar, confirma que el servidor externo puede proporcionar las extensiones y los privilegios necesarios, crea una copia de seguridad restaurable y cambia una sola capa de actualización a la vez para saber qué componente introdujo el fallo.

Empieza por el contrato de la base de datos externa

Documenta el endpoint de la base de datos, el nombre de la base de datos, la cuenta de servicio, el modo TLS, la versión principal de PostgreSQL, los nombres y las versiones de las extensiones instaladas y quién puede actualizar esas extensiones. Conserva este registro junto a la definición del despliegue de Immich para que la recreación de un contenedor no vuelva a conectarse silenciosamente a otro servidor o a otra base de datos.

Es posible utilizar un servidor PostgreSQL preexistente, pero no es la configuración recomendada predeterminada de Immich. En las versiones actuales, la configuración con una base de datos independiente requiere pgvector y VectorChord; se sabe que Immich funciona con PostgreSQL 14 a 19, pgvector >=0.7 y <0.9, y VectorChord >=0.3 y <2.0. Vuelve a comprobar estos rangos antes de cada actualización porque pueden cambiar.

Planifica los privilegios antes de la migración. Immich normalmente espera un rol de base de datos con permisos de superusuario; ejecutarlo sin ellos es una configuración avanzada que puede requerir intervención manual durante las actualizaciones, y las copias de seguridad automatizadas actuales de la base de datos requieren permisos de superusuario. Si tu proveedor externo no puede cumplir esos requisitos, detente antes de trasladar el estado de producción.

Verifica la compatibilidad de PostgreSQL y las extensiones antes de cambiar nada

Enumera las versiones actuales y de destino de PostgreSQL junto con todas las extensiones de las que depende Immich. Una actualización principal de PostgreSQL puede requerir binarios de extensiones compilados para la versión principal de destino, mientras que una actualización de Immich puede requerir una extensión más reciente o un comportamiento de migración distinto aunque PostgreSQL siga iniciándose correctamente.

Los archivos de los paquetes de extensiones y el estado SQL de las extensiones deben trasladarse deliberadamente con la base de datos, en lugar de suponerse que se actualizarán junto con PostgreSQL. Revisa las dependencias de actualización de las extensiones de PostgreSQL antes de cambiar la versión principal de la base de datos o los paquetes de extensiones que requiere Immich.

Si tu proveedor externo no te permite instalar o actualizar la extensión requerida, cambiar la configuración de precarga compartida cuando sea necesario o conceder los privilegios que necesita la migración, detente antes de actualizar Immich. Una base de datos que acepta consultas ordinarias puede seguir siendo inadecuada para la siguiente migración de la aplicación.

Mantén separadas las actualizaciones principales de la base de datos y las de Immich

Evita combinar una actualización principal de PostgreSQL, una actualización de extensiones y una actualización de la aplicación Immich en un mismo periodo de mantenimiento, a menos que ya hayas ensayado la secuencia completa. Cuando se modifican varios límites de compatibilidad a la vez, un fallo al iniciar ya no indica qué capa lo causó.

Las actualizaciones menores de PostgreSQL y las actualizaciones de versión principal son tareas de mantenimiento distintas, y las actualizaciones principales requieren preparar primero el entorno de destino, incluidas las extensiones de terceros. Mantén las actualizaciones de versión principal de PostgreSQL separadas de una actualización de la aplicación Immich siempre que sea posible, para que un fallo al iniciar siga teniendo un único cambio claro que investigar.

En un servidor doméstico, la secuencia de menor riesgo suele ser: crear copias de seguridad, verificar una restauración, actualizar una capa, ejecutar la validación y continuar después. Si una versión de Immich requiere un cambio en la base de datos, sigue el orden indicado para esa versión en lugar de aplicar una receta genérica de actualización de PostgreSQL.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Conserva una vía de reversión que abarque tanto la base de datos como los archivos multimedia

Una base de datos externa facilita olvidar que el estado de Immich está dividido entre PostgreSQL y la biblioteca multimedia. Haz una copia de seguridad de la base de datos mediante un método coherente con la base de datos y conserva el estado relevante de los archivos multimedia y la configuración de la misma ventana de recuperación antes de una migración que pueda cambiar los esquemas o los metadatos de los recursos.

El estado de la base de datos, los archivos de la aplicación, la configuración y las cargas deben coincidir en el momento de la restauración. Utiliza una copia de seguridad coherente del contenedor de la base de datos como modelo de aceptación, no simplemente como una comprobación de si PostgreSQL se inicia.

No consideres lista la reversión hasta saber qué ocurre en ambos lados si la migración de la aplicación se completa parcialmente. Conserva la versión anterior de la aplicación, la definición del despliegue, la copia de seguridad de la base de datos y el estado de los archivos multimedia durante el tiempo suficiente para recuperarte sin sobrescribir el único estado conocido como correcto con datos más recientes.

Valida la actualización como una aplicación, no solo como una conexión de base de datos

Después del cambio, confirma que PostgreSQL acepta el rol de Immich previsto, que las extensiones necesarias están presentes con las versiones esperadas y que la migración de Immich se completa sin errores repetidos de la base de datos. Una conexión TCP correcta o `SELECT 1` demuestra conectividad, no compatibilidad con la aplicación.

Después, utiliza Immich con normalidad: carga álbumes antiguos, abre fotos y vídeos representativos, realiza búsquedas, revisa los usuarios o el uso compartido cuando corresponda y sube un recurso desechable. Observa los registros de la aplicación y de la base de datos durante estas acciones para detectar extensiones ausentes, errores de permisos, fallos de migración o reintentos repetidos.

Solo después de que la aplicación supere esas comprobaciones debes reanudar la retención normal de copias de seguridad y eliminar la copia de reversión. Si la base de datos externa hace que las actualizaciones habituales de Immich dependan repetidamente de tareas manuales con extensiones o privilegios que no puedes ensayar de forma fiable, el ciclo de vida de una base de datos dedicada predeterminada es la opción operativa más segura.