Migrar PostgreSQL local a una base de datos gestionada

Migrar una base de datos no consiste solo en copiar filas. El destino debe admitir el esquema y las extensiones del origen, la aplicación tiene que conectarse de forma segura y necesitas un plan probado para volver atrás si algo falla. Esta guía explica cómo mover una base PostgreSQL desde tu ordenador o un servidor que administras a un servicio gestionado. No trata de cambiar modelos de Prisma ni de ejecutar una migración de esquema: para eso consulta la guía de migraciones Prisma en producción.

Decide quién se ocupará del motor

Una base gestionada te puede ahorrar instalar y actualizar PostgreSQL, mantener el servidor y ocuparte de su rutina de copias. Con un VPS tienes más control del sistema, la configuración y las extensiones, pero también asumes los parches, los permisos, la monitorización, las copias y las pruebas de restauración. Hostbrid ofrece tanto bases de datos gestionadas como VPS Cloud; eso no significa que cualquier carga o extensión esté admitida en cualquiera de las dos opciones.

La oferta pública de Hostbrid incluye PostgreSQL, MariaDB y Redis. Describe copias diarias y, en el plan DB-HA, tres réplicas de PostgreSQL con conmutación automática. También indica que la base no tiene IP pública por defecto y se alcanza desde servicios compatibles de la cuenta; el acceso desde fuera requiere autorizar una IP. Revisa los detalles y límites actuales del producto antes de crear el destino. Una copia diaria ayuda, pero no demuestra que hayas probado tu propia restauración ni garantiza que la aplicación pueda cambiar de servidor sin ajustes.

Mantén PostgreSQL en tu VPS si dependes de acceso de superusuario, de extensiones o parámetros que el plan gestionado no expone, o de una forma de despliegue que el producto no admite. Elige la opción gestionada solo tras comprobar la versión principal, las extensiones disponibles, el almacenamiento, los límites de conexiones y la ruta de red autorizada. La página comercial es la referencia de las prestaciones vigentes; la documentación de PostgreSQL explica cómo exportar y restaurar.

Haz inventario antes de exportar

Anota la versión principal de PostgreSQL del origen, el tamaño de la base, codificación, criterios de ordenación, extensiones instaladas y roles de la aplicación. Puedes consultar las extensiones con esta sentencia:

SELECT extname, extversion FROM pg_extension ORDER BY extname;

Confirma que las extensiones necesarias existan en el destino. Revisa propietarios, permisos, políticas de seguridad por fila, secuencias, objetos grandes y tareas programadas. pg_dump exporta una base de datos; no incluye automáticamente todos los roles del clúster ni cada parámetro del servidor. Si la aplicación depende de alguno, crea una alternativa deliberada en el destino en vez de restaurar el clúster de origen sin revisión. No transfieras datos que no tengas autorización para mover; si puedes, empieza con una muestra anonimizada.

Antes de restaurar, crea la base de destino y comprueba la conexión. En Hostbrid, consulta en el panel el host, puerto, nombre de base, usuario e instrucciones TLS. El servicio no acepta conexiones públicas arbitrarias por defecto. Ejecuta la migración desde un recurso autorizado para alcanzar la base o solicita el acceso temporal más restringido que permita el producto desde una IP de confianza. No abras PostgreSQL a todo Internet. Retira el permiso temporal del equipo cuando termines.

Usa una versión del cliente PostgreSQL que pueda leer la versión del servidor de origen y sea compatible con el destino. La referencia oficial de pg_dump explica esta compatibilidad: se espera que un volcado se pueda cargar en versiones de servidor posteriores, pero un cliente de una versión principal más nueva no es una opción segura para restaurar en un servidor anterior. Comprueba la combinación exacta; no des por hecho que el salto entre versiones no requiere cambios.

Crea un archivo protegido y restaura en una base vacía

Guarda las credenciales del origen y del destino en un archivo de contraseñas libpq con permisos restringidos o en un gestor de secretos. No escribas contraseñas en el historial de shell, registros ni repositorios. Si usas .pgpass, limita los permisos al propietario (0600). Sigue el modo TLS y la validación de certificados que indique el servicio de destino; no desactives la verificación para forzar una conexión.

Con el host, el puerto, la base y el usuario del origen disponibles para el cliente, crea un volcado de formato personalizado:

pg_dump --format=custom --host="$SOURCE_HOST" --port="$SOURCE_PORT" \
  --username="$SOURCE_USER" \
  --dbname="$SOURCE_DB" --file=before-migration.dump
pg_restore --list before-migration.dump

pg_dump conecta con una base de datos y crea una exportación lógica consistente mientras el servidor sigue activo. El formato personalizado permite inspeccionar el archivo y restaurar partes concretas. En este ejemplo, --no-owner --no-acl en la restauración evita arrastrar al servicio nuevo los propietarios y permisos del servidor antiguo; los objetos quedan bajo el usuario del destino. Eso cambia los permisos, así que valida el usuario de la aplicación y sus permisos. Si debes conservar propietarios o roles de clúster, diseña esa parte por separado con la persona responsable de la base.

Crea una base de destino vacía con las extensiones necesarias y restaura allí el archivo:

pg_restore --exit-on-error --no-owner --no-acl \
  --host="$TARGET_HOST" --port="$TARGET_PORT" --username="$TARGET_USER" \
  --dbname="$TARGET_DB" before-migration.dump

No añadas --clean a una restauración de producción para silenciar errores: puede borrar objetos existentes. Restaura primero en una base vacía y detente si pg_restore informa de errores. La referencia oficial de pg_restore documenta las opciones del archivo y la respuesta a fallos. Conserva el volcado cifrado y con acceso restringido hasta validar el destino; después aplica tu política de retención y borrado.

Valida antes de cambiar la aplicación

Compara las tablas y los recuentos aproximados de las más importantes. Revisa restricciones, índices, secuencias, permisos, zona horaria y valores representativos con acentos o datos binarios. En un entorno de prueba, conecta la aplicación al destino y prueba inicio de sesión, escrituras, tareas en segundo plano y referencias a archivos. El volcado no mueve archivos subidos, almacenamiento de objetos, datos de Redis, correo, variables de entorno ni integraciones externas.

Si es una base de desarrollo sin escrituras de producción, quizá baste con una exportación. Para un servicio activo, programa una ventana: activa modo mantenimiento o solo lectura, detén escritores y tareas, genera el volcado final, restáuralo y cambia el único DATABASE_URL o secreto equivalente. Es un cambio planificado, no una promesa de cero interrupciones. Haz una prueba funcional antes de reabrir escrituras. No mantengas ambas bases aceptando escrituras salvo que tengas replicación y resolución de conflictos probadas.

Conserva el origen intacto y en solo lectura hasta que el destino supere sus comprobaciones. Si vuelves atrás después de que usuarios hayan escrito en la base nueva, esos cambios no estarán en el origen. Decide de antemano si aceptarás perder las escrituras recientes, reproducirás los cambios o mantendrás el servicio en mantenimiento para reconciliar los datos. Una copia solo queda verificada después de restaurarla en la práctica.

Después del cambio, observa errores de conexión y consumo de almacenamiento/conexiones. Rota credenciales si el archivo o el acceso temporal pudieron quedar expuestos. Los cambios de esquema posteriores son otra tarea; consulta la lista de comprobación para Prisma. Si la base gestionada cumple tus requisitos de extensiones y red, compara los planes de bases de datos Hostbrid. Si necesitas administrar el motor, revisa los planes VPS. Resuelve dudas de compatibilidad antes de mover datos de producción.