Cómo hospedar una base de datos en la nube

Hospedar una base de datos significa mantener un servidor de base (PostgreSQL, MySQL, MongoDB o Redis) encendido todo el tiempo, con disco, red y credenciales, y lograr que tu aplicación hable con él. Instalar el motor rara vez es lo difícil. El trabajo real está en decidir dónde corre, quién puede conectarse y cómo recibe la aplicación la contraseña sin que termine en el repositorio.

Los pasos de abajo van desde elegir el lugar hasta verificar la conexión. Los ejemplos usan PostgreSQL y Node.js, pero la lógica vale para los demás motores.

¿Dónde puedo hospedar una base de datos?#

Hay tres caminos comunes:

• En tu propio equipo: ideal para desarrollar. No sirve para producción, porque la base queda fuera de línea cuando el equipo se apaga y nadie de afuera puede llegar a ella.
• En un servidor que administras (VPS): instalas el motor y te ocupas del firewall, las actualizaciones, el disco y las copias. Tienes control total y todo el trabajo que eso implica.
• En un servicio de hospedaje de bases de datos: el proveedor levanta la instancia y te entrega la dirección y las credenciales. Tú cuidas el esquema y los datos, no el sistema operativo.

Si aún no elegiste el motor, lee antes Qué base de datos elegir. Para el impacto en el presupuesto, mira Cuánto cuesta una base de datos en la nube.

¿Qué debo decidir antes de crear la base?#

Cinco decisiones definen tamaño y costo:

1. Motor: relacional (PostgreSQL, MySQL), de documentos (MongoDB) o clave-valor en memoria (Redis).
2. Memoria: Redis guarda el conjunto de datos en RAM. Los demás usan RAM como caché y disco para el resto.
3. Espacio en disco: tamaño actual de los datos más margen de crecimiento.
4. Ubicación: lo más cerca posible de la aplicación, porque cada consulta paga la latencia de red.
5. Copias: cada cuánto harás copias y cómo probarás la restauración. Detalles en Cómo hacer backup de una base de datos.

¿Cómo es una cadena de conexión?#

Para PostgreSQL, la documentación de libpq define el formato de URI:

postgresql://usuario:clave@host:5432/nombre_de_la_base?sslmode=require

Cada parte cumple un papel: el esquema (postgresql:// o postgres://), usuario:clave, el host, el puerto (5432 es el valor habitual de PostgreSQL), el nombre de la base y los parámetros tras ?. sslmode=require obliga a que la conexión use TLS, pero sin un certificado raíz configurado el cliente no verifica la identidad del servidor (eso exige verify-ca o verify-full).

Ojo con los caracteres especiales. Según la documentación, los símbolos con significado propio en la URI necesitan percent-encoding. Una contraseña p@ss debe pasar a p%40ss. Si la conexión falla con error de autenticación y la contraseña parece correcta, empieza por ahí. En Node.js, encodeURIComponent("p@ss") hace la conversión.

MySQL (mysql://), MongoDB (mongodb:// o mongodb+srv://) y Redis (redis://) siguen la misma idea: una URL con usuario, contraseña, host y puerto.

¿Cómo guardo la cadena de conexión de forma segura?#

Nunca escribas la contraseña en el código. Pon la cadena en una variable de entorno, por ejemplo DATABASE_URL, y léela en tiempo de ejecución.

En el archivo .env (nunca lo subas al repositorio):

DATABASE_URL="postgresql://usuario:clave@host:5432/nombre_de_la_base?sslmode=require"

Agrega .env al .gitignore. En producción, define la variable en el panel del hospedaje en lugar de enviar el archivo. El concepto se explica en Qué son las variables de entorno.

¿Cómo conecto una aplicación Node.js?#

Instala el cliente pg (node-postgres):

npm install pg

Los ejemplos usan ES modules (import), así que tu package.json necesita "type": "module". Crea db.js. Un Pool reutiliza conexiones en vez de abrir una por consulta y acepta la cadena de conexión directamente:

import pg from "pg";

const { Pool } = pg;

export const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

Y un script de prueba, probar.js:

import { pool } from "./db.js";

const { rows } = await pool.query("SELECT NOW() AS ahora");
console.log("Conectado. Hora del servidor:", rows[0].ahora);
await pool.end();

Ejecútalo con node --env-file=.env probar.js (la flag requiere una versión reciente de Node.js). pg también lee PGHOST, PGUSER, PGPASSWORD, PGPORT y PGDATABASE cuando creas el Pool sin argumentos, las mismas variables que usa psql.

Un detalle sobre TLS: por defecto, pg no sigue la regla de libpq descrita arriba. Con sslmode=require verifica el certificado del servidor, y un certificado que Node.js no reconoce (uno autofirmado, por ejemplo) produce un error. Si el proveedor te da el certificado de su CA, apúntalo con sslrootcert; para la semántica de libpq, agrega uselibpqcompat=true a la cadena.

Crea un único Pool e impórtalo en los demás archivos. Abrir un Pool por petición agota rápido las conexiones de la base.

¿Cómo verifico que la conexión funciona?#

Tres pruebas, de la más simple a la más completa:

1. Consulta mínima: SELECT NOW(), como en el script anterior. Si devuelve resultado, red, credenciales y TLS están bien.
2. Cliente de línea de comandos: psql "$DATABASE_URL" muestra si la base responde fuera de tu aplicación, lo que separa los problemas de red de los de código.
3. Escritura y lectura: crea una tabla de prueba, inserta una fila, léela y bórrala. Así confirmas que el usuario puede escribir, no solo leer.

¿Qué errores aparecen con más frecuencia?#

Casi siempre la causa está en la cadena, en el firewall o en cómo se usan las conexiones. Lee el mensaje completo antes de cambiar nada.

Cómo hacerlo en Square Cloud#

En Square Cloud, la base sigue el tercer camino de la lista: tú creas la instancia y te ocupas del esquema y de los datos. El hosting de MongoDB, PostgreSQL, MySQL y Redis empieza en el plan Standard (Hobby no incluye bases de datos). De las decisiones de arriba, motor y memoria son campos del panel: el motor viene siempre en una versión reciente, y la memoria empieza en 512 MB para Redis y 1024 MB para los demás. La ubicación ya está resuelta, porque la base se aprovisiona en segundos en el mismo datacenter que tus aplicaciones, con una latencia media de cerca de 1 ms.

El panel te entrega la URL de conexión completa (se muestra una vez al crearla; restablecer la contraseña la muestra de nuevo) y los certificados para descargar. TLS es obligatorio: el cliente confía en la CA descargada y, en PostgreSQL y MongoDB, también presenta el certificado .pem. En pg, esos archivos van en la opción ssl del Pool (ca, cert y key); en ese caso, quita sslmode de la URL, porque los parámetros de la cadena reemplazan esa opción. La URL pasa a ser una variable de entorno de la aplicación, desde el panel, la API, la CLI o la extensión de VS Code, y el cambio se aplica en el siguiente reinicio, sin rebuild. Como la base acepta conexiones desde fuera, las tres pruebas de la sección anterior también corren desde tu máquina o tu CI, con los mismos certificados.

Para la decisión sobre copias, puedes tomar snapshots manuales cuando quieras, y todo plan que incluye bases de datos hace también un snapshot automático diario, que se guarda 7 días. Un snapshot se restaura en la misma base, en otra del mismo motor o en una base nueva. PostgreSQL es el nativo, sin extensiones, y Redis tiene persistencia.

Empieza por el hosting de PostgreSQL, el motor de los ejemplos, o consulta las bases disponibles hoy en Bases de datos.