Configurar una base de datos en producción es uno de los pasos más críticos al llevar una aplicación al mundo real. Cuando trabajas con Node.js, PostgreSQL y Heroku, necesitas ajustar variables de entorno, conexiones SSL y migraciones para que todo funcione correctamente. A continuación se explica paso a paso cómo lograrlo, incluyendo los errores más comunes y cómo resolverlos.
¿Por qué usar una base de datos gestionada en Heroku?
Administrar una base de datos por cuenta propia puede ser complejo: backups, seguridad y disponibilidad requieren atención constante. Proveedores como Heroku, Digital Ocean o Amazon ofrecen bases de datos autogestionadas que simplifican este trabajo [1:10]. Heroku proporciona un addon de PostgreSQL que se conecta directamente al servicio desplegado.
- No es obligatorio que la base de datos esté en el mismo proveedor que el backend.
- Puedes tener tu servidor en Heroku y tu base de datos en Amazon u otro servicio.
- El plan hobby-dev es gratuito, aunque no incluye backups ni se recomienda para datos críticos en producción [2:00].
- Planes desde nueve dólares al mes ya ofrecen mayor capacidad y disponibilidad.
Para agregar PostgreSQL a tu proyecto existente, se utiliza el comando heroku addons:create heroku-postgresql --plan hobby-dev [3:30]. Este comando crea la base de datos y genera automáticamente una variable de entorno llamada DATABASE_URL con toda la información de conexión.
¿Cómo configurar la conexión con DATABASE_URL?
Heroku inyecta la URL completa de conexión a través de la variable de entorno DATABASE_URL [4:40]. Esto significa que en producción no necesitas separar usuario, contraseña, host y puerto; todo viene empaquetado en una sola cadena.
¿Conviene unificar la URL en desarrollo y producción?
Una estrategia práctica es utilizar la misma estructura de connection string tanto en desarrollo como en producción [6:10]. En tu archivo .env de desarrollo, armas la URL manualmente:
DATABASE_URL=postgres://nico:admin123@localhost:5432/mi_base_de_datos
En producción, Heroku la proporciona automáticamente. Así evitas condicionales innecesarios para construir la conexión.
¿Qué es la configuración SSL y por qué es necesaria?
Heroku requiere que las conexiones a PostgreSQL utilicen SSL (Secure Sockets Layer). La configuración incluye ssl: { rejectUnauthorized: false }, pero solo debe activarse en producción [7:50]. En desarrollo genera conflictos.
Para manejar esto se crea una variable isProd que verifica si el entorno es production:
javascript
const isProd = config.env === 'production';
const options = {};
if (isProd) {
options.ssl = { rejectUnauthorized: false };
}
Cuando trabajas con Sequelize (referido como SQLite en la clase), la configuración SSL no se pasa directamente, sino a través de dialectOptions [13:00]:
javascript
if (isProd) {
options.dialectOptions = {
ssl: { rejectUnauthorized: false }
};
}
Este detalle es fundamental: el pool nativo de pg acepta ssl directamente, pero Sequelize necesita dialectOptions.
¿Cómo ejecutar migraciones en producción?
Las migraciones son el mecanismo versionado que crea y modifica tablas en la base de datos [15:20]. Sin correr migraciones en producción, las tablas no existen y cualquier consulta fallará.
¿Qué comando se usa para correr migraciones en Heroku?
El comando heroku run npm run migrations:run ejecuta las migraciones directamente en el servidor de producción [16:30]. Aquí aparecen tres run distintos:
- heroku run: indica a Heroku que ejecute una instrucción.
- npm run: ejecuta una tarea definida en
package.json.
- migrations:run: nombre de la tarea que corre las migraciones.
¿Qué errores comunes aparecen durante el deployment?
Durante el proceso surgieron varios problemas reales que vale la pena conocer:
- Paquete no encontrado: Heroku solo instala dependencias de producción. Si
sequelize-cli está en devDependencies, no se instala y las migraciones fallan [17:40]. La solución es moverlo a dependencies.
- Error de SSL: si el archivo de configuración de migraciones no usa
dialectOptions correctamente, la conexión falla [19:10].
- Fallo en migraciones específicas: aunque la primera migración corra bien, las siguientes pueden fallar por dependencias entre tablas o roles inexistentes [21:00].
Cada error se resuelve leyendo el mensaje con calma, identificando la causa y haciendo un nuevo commit con el ajuste. El ciclo de corregir, hacer commit y redesplegar es normal en los primeros deployments.
Para hacer deployment desde una rama específica sin modificar main, se usa git push heroku production:main [14:30], indicando que la rama production local se envíe hacia main en Heroku.
¿Has tenido errores similares al correr migraciones en producción? Comparte en los comentarios qué crees que puede causar el fallo en la migración de Add role.
