PostgreSQL autoalojado en un VPS: olvídate de los precios de las bases de datos administradas

Cómputo. Almacenamiento. Retención de copias de seguridad.

La exportación de snapshots que olvidaste. La tarifa de tráfico de salida del entorno de staging que ejecutó un «pg_dump» el martes pasado.

Nadie abre la factura de su base de datos administrada esperando que sea barata.

Pero, madre mía.

La diferencia entre Postgres por 25 $ al mes y lo que acaba cargándose en la tarjeta se ha vuelto enorme, y un VPS de 4 GB al precio de un solo complemento de Supabase ya puede ejecutar toda tu base de datos con margen de sobra para que el sistema operativo almacene en caché las páginas más usadas.

Autoalojar una base de datos Postgres en producción ya no es la pesadilla operativa que era antes. El repositorio del PostgreSQL Global Development Group (PGDG) es sólido; las instalaciones modernas de PostgreSQL (v14+) usan por defecto el cifrado de contraseñas SCRAM-SHA-256, y el antiguo MD5 está oficialmente obsoleto desde la v18. Hoy, los motivos para quedarse en RDS, Supabase o Neon son operativos, no técnicos.

Hablamos de facturas reales, de carga operativa real y de cómo es de verdad el hosting moderno de Postgres.

¿Cuánto cuesta realmente autoalojar PostgreSQL en un VPS?

PostgreSQL autoalojado en un VPS de 4 GB suele costar una fracción del precio equivalente de RDS, Supabase Pro o Neon Scale, una vez que sumas el almacenamiento, las copias de seguridad y el tráfico de salida a la factura administrada.

PostgreSQL es la base de datos que usa el 55,6 % de los desarrolladores, según la Developer Survey 2025 de Stack Overflow, y la más popular por segundo año consecutivo. También es una base de datos que puedes gestionar tú mismo sin complicaciones.

Comparativa para una carga de trabajo representativa de un equipo pequeño (4 GB de RAM, ~100 GB de datos, carga de escritura baja a moderada, una sola región), con precios de mayo de 2026:

El precio bajo demanda de RDS db.t4g.medium ronda los 0,065 $ por hora, o unos 47,45 $ al mes solo de cómputo.

Si le sumas 100 GB de almacenamiento gp3 a unos 0,115 $/GB-mes y copias de seguridad automáticas, una instancia Single-AZ se acerca a los 60 $/mes. Activa la conmutación por error Multi-AZ y el cómputo prácticamente se duplica, lo que lleva una configuración apta para producción a 100 $/mes o más.

No es una diferencia pequeña.

Autoalojar sale más barato porque el trabajo que pagaba la factura administrada lo haces tú. Disciplina operativa, guardias, las 2 de la madrugada cuando se llena el disco. La alternativa administrada con la que comparas puede tener otro precio mínimo el próximo trimestre, así que haz los números con tu propia factura antes de decidirte.

¿Cuándo tiene sentido autoalojar PostgreSQL?

Autoalojar PostgreSQL en un VPS tiene sentido cuando en tu equipo hay soltura básica con Linux, una carga de trabajo estable, un conjunto de trabajo de tamaño predecible y un motivo real para escapar de la factura administrada.

No funciona si no tienes capacidad operativa, si tienes requisitos regulados de alta disponibilidad que no puedes montar tú mismo o si tu tráfico va a picos y se beneficia de escalar al instante.

Hay tres factores que determinan esta decisión: el coste, la privacidad y la soberanía de los datos, y el control.

Dónde gana claramente el autoalojado:

• Tráfico estable en una sola región con un conjunto de trabajo predecible.
• Aplicaciones SaaS pequeñas y medianas con una sola base de datos Postgres y un equipo cómodo con Linux.
• Cargas de trabajo sensibles a la privacidad en las que la base de datos no debería estar en la infraestructura de otro.
• Equipos atentos al coste cuya factura administrada ya supera lo que compensa la molestia operativa.

Dónde gana claramente el administrado:

• Cargas de trabajo con picos que se benefician de escalar hacia arriba y hacia abajo al instante.
• Configuraciones multirregión en las que la replicación global es el producto.
• Entornos regulados que necesitan alta disponibilidad lista para usar, certificaciones de cumplimiento y registros de auditoría.
• Equipos sin capacidad operativa libre y sin intención de crearla.

La cifra de un ahorro del 40 % al 60 % se cita mucho. Fíjate bien en su fecha.

En 2021, Rupesh Desai, autor de AWS, documentó que PostgreSQL en EC2 costaba entre un 40 % y un 60 % menos que RDS con especificaciones equivalentes, un dato anterior a la mayoría de las familias de instancias actuales de RDS.

La versión actual es el análisis de costes de byteiota, publicado a finales de 2025, que afirma que RDS es entre un 75 % y un 88 % más caro que un hardware dedicado equivalente.

El punto de equilibrio real lo marcan las horas de operación, no el coste del servidor.

¿Cómo eliges el tamaño de VPS adecuado para PostgreSQL?

La mayoría de las bases de datos de aplicaciones en producción funcionan sin problemas con 4 GB de RAM y almacenamiento NVMe. Los conjuntos de datos más grandes, muchas conexiones concurrentes o las cargas analíticas elevan el requisito a 8 GB, 16 GB o más.

La RAM determina qué parte de tu conjunto de trabajo puede mantener Postgres en memoria; cuando las páginas más usadas pasan al disco, las consultas se ralentizan. NVMe importa porque Postgres es sensible a la latencia de lectura aleatoria de las páginas más usadas y al rendimiento de escritura del registro de escritura anticipada (WAL).

Las recomendaciones habituales de ajuste de PostgreSQL empiezan por:

• shared_buffers en torno al 25 % de la RAM del sistema.
• effective_cache_size en torno al 50-75 % de la RAM del sistema.
• work_mem con un tamaño conservador, según la complejidad de las consultas concurrentes y no solo la RAM total.

En un VPS de 4 GB, eso suele significar asignar alrededor de 1 GB a shared_buffers y dejar memoria suficiente para que la caché de páginas de Linux guarde los datos a los que se accede con frecuencia. Ese equilibrio explica en parte por qué un servidor modesto de 4 GB puede con muchas cargas de producción pequeñas y medianas.

La relación entre planes y cargas de trabajo que necesitas conocer:

Los planes de hosting VPS de DreamHost te ofrecen acceso root, almacenamiento NVMe y ancho de banda sin límite con una factura mensual predecible.

Son las cuatro cosas de las que depende una carga de trabajo de Postgres autoalojado.

¿Cómo instalas PostgreSQL en un VPS?

Instalar PostgreSQL en un VPS se resume en cinco pasos.

1. Aprovisiona el VPS: elige un plan con RAM suficiente para tu conjunto de trabajo (Stack 8/8 GB para producción). El sistema operativo recomendado es Ubuntu 24.04 LTS. Conéctate por SSH con autenticación por clave, no con contraseña.
2. Instala desde el repositorio oficial de PGDG: el ‘apt install postgresql’ de la distribución va con retraso en las versiones principales. Añade el repositorio apt de PGDG y luego ‘sudo apt install postgresql-18.’ Compruébalo con ‘sudo systemctl status postgresql’
3. Define la contraseña de postgres y crea el rol de tu aplicación: ejecuta sudo -i -u postgres, luego psql y después password postgres. Crea un rol dedicado con privilegios mínimos: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ y ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Configura bien el listener: abre /etc/postgresql/18/main/postgresql.conf. Define listen_addresses = ‘localhost’ si la aplicación y la base de datos están en el mismo servidor, o vincúlalo a una IP privada si la aplicación se ejecuta en otro VPS. Evita vincular PostgreSQL a 0.0.0.0 en una interfaz accesible públicamente. Los bots automatizados escanean y atacan por fuerza bruta sin descanso las instancias de PostgreSQL expuestas.
5. Protege «pg_hba.conf» y UFW: edita pg_hba.conf para permitir solo las IP de aplicación que realmente necesites, con «scram-sha-256» como método de autenticación. Configura UFW para permitir el puerto 5432 solo desde esas mismas IP. Usa un túnel SSH para las herramientas de administración (y, por favor, no abras el 5432 a internet).

Prueba esto desde otra máquina: psql -h <vps-ip> -U postgres.

Si una IP no autorizada recibe un tiempo de espera agotado o una conexión rechazada, normalmente significa que el listener y las reglas del cortafuegos están haciendo su trabajo. Si desde internet aparece una petición de contraseña, algo está mal configurado. Con Postgres en marcha, la configuración es solo la mitad del trabajo.

¿Cómo proteges PostgreSQL en un VPS?

PostgreSQL en un VPS se protege en tres capas, además de una buena gestión de roles y una rutina de parches.

1. Autenticación: usa scram-sha-256 en las instalaciones nuevas y elimina las antiguas reglas md5 de pg_hba.conf. La documentación de PostgreSQL ya advierte de que la compatibilidad con contraseñas cifradas con MD5 está obsoleta y se eliminará en una versión futura.
2. Red: vincula PostgreSQL a «localhost», a una IP privada o a una interfaz a la que solo puedan llegar tus servidores de aplicaciones. Evita vincularlo a una interfaz accesible públicamente. Añade UFW por encima y permite el puerto 5432 solo desde IP de aplicación de confianza.
3. Cifrado en tránsito: activa TLS en cualquier conexión que cruce un límite de red. Define ssl = on en postgresql.conf y usa reglas hostssl … scram-sha-256 en pg_hba.conf para que los clientes no puedan recurrir sin avisar a conexiones sin TLS. Los certificados autofirmados son aceptables para el tráfico interno si los clientes los verifican correctamente.
4. Roles: las conexiones de la aplicación deben usar un rol con privilegios mínimos que solo tenga los permisos necesarios para los esquemas de esa aplicación. El superusuario es para migraciones y emergencias.
5. Parches: usa el repositorio apt de PGDG para tener los paquetes de PostgreSQL al día. Activa las actualizaciones de seguridad automáticas del sistema operativo, pero programa las de PostgreSQL de forma deliberada para que un reinicio inesperado no se convierta en el incidente de la semana.

Tu lista de comprobación de seguridad:

• Usa solo scram-sha-256; desactiva md5.
• Vincula «listen_addresses» a localhost o a una IP privada.
• Las reglas de UFW permiten el 5432 solo desde IP de confianza.
• SSL/TLS activado en cualquier conexión que cruce la red.
• La aplicación se conecta con un rol de privilegios mínimos, nunca como «postgres».
• Actualizaciones de seguridad automáticas activadas.
• Ninguna línea «host all all 0.0.0.0/0 md5» en «pg_hba.conf». Nunca.

Ese último punto es la advertencia clave.

Un puerto 5432 público con credenciales débiles es un objetivo conocido de criptominería y ataques de fuerza bruta. Los bots automatizados escanean continuamente las instancias de PostgreSQL expuestas en busca de cuentas predeterminadas, contraseñas filtradas o reglas de pg_hba.conf demasiado permisivas.

Las instancias de Postgres accesibles públicamente con autenticación débil suelen verse comprometidas con una rapidez alarmante. Una base de datos expuesta directamente a internet sin controles de red adecuados, TLS ni aislamiento de roles es el tipo de error que acaba en un informe de incidentes. Y aun bien configurada, una base de datos está a un fallo de disco de perder sus datos.

¿Cómo haces copias de seguridad y replicas PostgreSQL en un VPS?

Las copias de seguridad de PostgreSQL en un VPS usan uno de tres mecanismos, según el fallo del que quieras protegerte: copias lógicas con pg_dump para la portabilidad, copias físicas con pg_basebackup más archivado de WAL para la recuperación a un momento concreto, y replicación en streaming para la alta disponibilidad.

Las copias lógicas sirven para migraciones, restauraciones parciales y para refrescar entornos de desarrollo. Ejecuta pg_dump –format=custom –file=mydb.dump mydb_prod desde un cron job diario. El formato custom se comprime bien y, junto con el formato de directorio, admite las opciones de restauración en paralelo y selectiva de pg_restore. Envía el volcado a un Object Storage compatible con S3 fuera del VPS.

Las copias físicas sirven para restauraciones completas del sistema y para la recuperación a un momento concreto. pg_basebackup junto con el archivado continuo del registro de escritura anticipada (WAL) te permite recuperar cualquier momento entre la última copia base y el segmento WAL más reciente; es la opción apta para producción cuando la tolerancia a la pérdida de datos se mide en segundos, no en horas.

La replicación en streaming es la tercera opción. Una réplica de lectura en un segundo VPS es un standby en caliente para cargas con muchas lecturas o un destino rápido de conmutación por error. Esta configuración de replicación cuesta un segundo VPS, pero limita tu peor caída posible a unos minutos.

Haz una prueba de restauración cada mes. Los servicios administrados ya incluyen todo esto, y es parte de lo que recuperas con el ahorro de autoalojar. Si ya usas un proveedor administrado, salir es más sencillo de lo que parece.

¿Cómo migras de RDS, Supabase o Neon a un VPS?

Puedes migrar de un proveedor de Postgres administrado a un VPS en cuatro pasos.

1. Prepara el VPS de destino: usa exactamente la misma versión principal de Postgres que el origen. Instala PostgreSQL en el nuevo VPS siguiendo los pasos anteriores y, después, crea de antemano el rol y la base de datos de la aplicación.
2. Haz el volcado desde el origen: ejecuta pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. Las opciones –no-owner y –no-privileges eliminan los permisos de rol propios del proveedor, que casi nunca se recrean bien en un servidor nuevo.
3. Restaura en el destino: ejecuta pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Presta atención a los avisos sobre extensiones. RDS, Supabase y Neon suelen activar extensiones que quizá no existan en Postgres estándar. Instala extensiones compatibles desde los paquetes de PGDG o postgresql-contrib antes de restaurar.
4. Cambia la cadena de conexión y verifica: primero apunta un entorno de staging al nuevo VPS, ejecuta tus pruebas y valida consultas de producción y flujos de la aplicación representativos antes de cambiar la cadena de conexión de producción. En aplicaciones con pocas escrituras, una breve ventana de mantenimiento durante el cambio final suele ser más sencilla que configurar la replicación. Mantén la base de datos de origen en línea y en modo de solo lectura durante varios días, por si necesitas volver atrás.

¿Qué cambia según el proveedor?

1. Desde RDS: los roles propios de RDS («rds_superuser», «rdsadmin») no existen en Postgres estándar; –no-owner y –no-privileges resuelven casi todo. Algunas extensiones administradas por RDS requieren instalación manual, y el tráfico de salida de AWS durante el volcado se factura.
2. Desde Supabase: el Postgres de Supabase es Postgres de verdad, pero sus capas de autenticación, almacenamiento y edge no se migran. El esquema de tu aplicación, sí. Sustituye esas capas por equivalentes autoalojados antes de hacer el cambio.
3. Desde Neon: después de la migración ya no tendrás ramificación; planifica copias de seguridad en su lugar. Volcar y restaurar es sencillo, pero hábitos operativos como las ramas instantáneas necesitan un flujo de trabajo alternativo.

La migración en sí suele llevar menos tiempo que elegir el plan de VPS. El tiempo de inactividad real es de minutos en bases de datos pequeñas, y más largo en las grandes por la reproducción del WAL. La mayoría de las instalaciones terminan aquí, pero hay un caso que te obliga a ir un paso más allá…

¿Cuándo añadir PgBouncer y cuándo quedarte con Postgres sin más?

La mayoría de las aplicaciones en un VPS de 4 GB no necesitan un agrupador de conexiones al principio. Añade PgBouncer cuando las conexiones simultáneas superen aproximadamente las 100 o cuando tu aplicación abra una conexión nueva por cada petición.

Las conexiones de PostgreSQL son pesadas porque cada una es un proceso completo del sistema operativo. Con 4 GB de RAM, no te conviene tener cientos de conexiones inactivas consumiendo memoria. El agrupador mantiene por un lado las costosas conexiones de Postgres y, por el otro, reparte conexiones ligeras y de corta duración a tu aplicación.

Hay dos modos de agrupación que importan:

• Agrupación por sesión: cada cliente obtiene una conexión al servidor durante toda la sesión. Es seguro para cualquier aplicación, no cambia el comportamiento y la mejora de rendimiento es menor.
• Agrupación por transacción: cada cliente obtiene una conexión al servidor para una sola transacción. La mejora de rendimiento es grande. Pierdes las funciones que dependen del estado de la sesión (sentencias preparadas, bloqueos consultivos, «LISTEN»/«NOTIFY»), salvo que la aplicación esté preparada para ello.

La mayoría de las aplicaciones SaaS pequeñas con un ORM que agrupa conexiones funcionan bien sin PgBouncer… hasta que dejan de hacerlo. La señal de que has cruzado la línea son los errores «FATAL: too many connections» o la presión de memoria por conexiones inactivas.

Instálalo con sudo apt install pgbouncer, configura /etc/pgbouncer/pgbouncer.ini con tu lista de bases de datos y el modo de agrupación y, después, apunta la aplicación a PgBouncer en el puerto 6432.

Tranquilo: sabrás cuándo lo necesitas.

La decisión final

La diferencia de coste es lo bastante real como para hacer cuentas con tu propia factura. Pero la configuración no es lo difícil.

Lo difícil es el trabajo operativo que pagabas con la factura del servicio administrado: copias de seguridad, simulacros de restauración, parches y monitorización.

Sea como sea, respira hondo antes de abrir la próxima factura.

Preguntas frecuentes sobre PostgreSQL en un VPS