PostgreSQL en VPS: base de datos fiable y controlada

Por qué autoalojar PostgreSQL en un VPS

Los beneficios concretos de un PostgreSQL autoalojado

• Coste fijo y previsible: sin facturación por GB, por IOPS ni por número de conexiones activas.
• Extensiones libres: pgvector para la IA, PostGIS para lo geoespacial, TimescaleDB para las series temporales.
• Control total de las copias de seguridad: pg_dump planificado, pg_basebackup o replicación física hacia un segundo VPS.
• Ajuste fino de postgresql.conf (shared_buffers, work_mem, WAL), imposible en la mayoría de las ofertas gestionadas.
• Soberanía de los datos: sus datos permanecen en una infraestructura que usted elige.
• Acceso de superusuario real para auditar, perfilar y optimizar sin abrir un ticket de soporte.

Requisitos de hardware y software

Desplegar PostgreSQL con Docker en producción

1. 01

   Preparar el VPS y el cortafuegos

   Conéctese por SSH, actualice el sistema con apt update && apt upgrade -y e instale Docker mediante curl -fsSL https://get.docker.com | sh. Bloquee el puerto 5432 desde el exterior con ufw deny 5432: la base de datos nunca debe estar expuesta directamente a Internet.

2. 02

   Escribir el docker-compose.yml

   Cree un servicio postgres:17, monte un volumen con nombre en /var/lib/postgresql/data y defina POSTGRES_PASSWORD, POSTGRES_DB y POSTGRES_USER mediante un archivo .env que nunca se suba al repositorio. Añada shm_size: 256mb para las ordenaciones voluminosas y un healthcheck con pg_isready.

3. 03

   Lanzar e inicializar la base de datos

   Arranque con docker compose up -d, compruebe los logs con docker compose logs -f postgres y después conéctese con docker compose exec postgres psql -U app -d mabase. Cree sus roles de aplicación con privilegios mínimos en lugar de utilizar el superusuario.

4. 04

   Exponer el acceso mediante un túnel o un proxy TLS

   Para un acceso remoto seguro, nunca abra 5432 en claro: utilice un túnel SSH (ssh -L 5432:localhost:5432) o coloque pgbouncer detrás de un reverse proxy. Active el SSL del lado de PostgreSQL con un certificado Let's Encrypt montado en el contenedor (ssl = on en postgresql.conf).

5. 05

   Ajustar la configuración

   Ajuste shared_buffers a alrededor del 25% de la RAM, effective_cache_size al 50-75% y work_mem según sus consultas. Active pg_stat_statements para identificar las consultas lentas. Utilice la herramienta PGTune como punto de partida.

6. 06

   Automatizar las copias de seguridad

   Programe un pg_dump diario mediante una tarea cron en el host, comprima en formato custom .dump y copie los archivos hacia un almacenamiento externo. Pruebe regularmente la restauración con pg_restore: una copia de seguridad no probada no existe.

7. 07

   Conectarse por primera vez

   pgAdmin no está publicado en Internet: abra un túnel desde su equipo (ssh -L 5050:127.0.0.1:5050 root@<IP>) y después http://127.0.0.1:5050, e inicie sesión con [email protected] y la contraseña facilitada. A continuación añada su servidor («Add New Server») con el host db, el puerto 5432, el usuario postgres y esa misma contraseña.

Configurar postgresql.conf para producción

1. 08

   shared_buffers: la caché de memoria de PostgreSQL

   Defina shared_buffers = 25% de la RAM total del VPS. En 8 GB de RAM, eso da 2 GB. Este parámetro controla el tamaño de la caché de páginas compartida entre todos los procesos de PostgreSQL — es la palanca más importante para las lecturas repetidas. Un archivo postgresql.conf personalizado montado vía Docker permite aplicar estos ajustes al arranque del contenedor.

2. 09

   work_mem y max_connections

   Establezca work_mem en función de sus consultas de ordenación y unión: de 4 a 16 MB es razonable para cargas mixtas. Atención: cada conexión puede asignar work_mem varias veces simultáneamente, así que multiplique por max_connections para estimar el pico de consumo de memoria. Para 100 conexiones de aplicación, max_connections = 150 es suficiente; más allá, use pgbouncer en modo transacción para multiplexar conexiones.

3. 10

   Logging y detección de consultas lentas

   Active logging_collector = on y log_min_duration_statement = <seuil_ms> (ms) para registrar todas las consultas que superen el umbral configurado. Combinar esto con pg_stat_statements (extensión a activar en shared_preload_libraries) ofrece una vista agregada de las consultas más costosas sin escanear cada archivo de log.

4. 11

   WAL y checkpoints

   Aumente wal_buffers a 16 MB y establezca checkpoint_completion_target en 0.9 para distribuir las escrituras de checkpoints en el tiempo. En SSD NVMe, random_page_cost = 1.1 (en lugar del valor por defecto 4.0) anima al planificador a elegir index scans en lugar de seq scans — un ajuste frecuentemente ignorado que cambia drásticamente los planes de ejecución en bases de datos grandes.

Copias de seguridad automáticas y estrategia de recuperación

Alta disponibilidad ligera sin Kubernetes

PostgreSQL self-hosted vs RDS vs Supabase vs Neon

Desplace la tabla

Resolución de problemas frecuentes en producción