Por qué reevaluar RDS en 2026
Amazon RDS for PostgreSQL es una base de datos gestionada sólida, pero su modelo de facturación está diseñado para que la factura siga el crecimiento de forma no lineal. Cada componente se factura por separado: el cómputo de la instancia, el almacenamiento gp3 por GB, las IOPS aprovisionadas, los nodos de replicación en Multi-AZ, las copias de seguridad más allá de la ventana incluida y las transferencias de datos salientes. Una instancia db.r6g.4xlarge en Multi-AZ con 500 GB de almacenamiento gp3 supera los 3 000 $/mes en us-east-1 con la tarifa bajo demanda. La misma carga de trabajo en un clúster Hetzner Cloud de tres nodos ronda los 835 $/mes, es decir, un ahorro de 2 315 $/mes, unos 27 800 $ en doce meses (fuente: selfhost.dev, mayo de 2026, HN item #48816129). Esa cifra corresponde a un clúster de alta disponibilidad completo. Para una base de datos de desarrollo, de staging o una carga de trabajo de negocio sin replicación, un único nodo basta por una fracción del costo. El contexto tarifario también ha evolucionado en 2026: Hetzner revisó sus tarifas en abril y de nuevo en junio de 2026, y OVHcloud subió sus VPS en abril de 2026. Estas subidas modifican las cifras absolutas, pero no cambian la lógica: el autoalojamiento sigue siendo estructuralmente más económico en cuanto la base supera algunas decenas de GB y el tráfico exige una instancia no burstable. La pregunta ya no es si el autoalojamiento sale más barato —las cifras lo confirman—, sino si la carga operativa compensa el ahorro obtenido.
Lo que gana al pasar a un VPS
- Costo fijo y previsible — sin facturación por GB, por IOPS adicionales ni por conexiones simultáneas; dimensiona su VPS una sola vez y el precio no cambia con el volumen de consultas.
- Extensiones sin restricciones — PostGIS, TimescaleDB, pg_partman, pgvector, citus: ninguna limitación arbitraria sobre las extensiones, a diferencia de las instancias RDS, donde la lista es cerrada y las extensiones no soportadas simplemente no están.
- Acceso root y configuración fina —
postgresql.conf,pg_hba.conf,huge_pages,wal_level, poolers de conexiones: ajusta cada parámetro sin pasar por una consola cloud y sin restricciones sobre las herramientas del sistema. - Versiones bajo control — usted decide cuándo pasar de PostgreSQL 16 a 17, sin ventana de mantenimiento impuesta ni obsolescencia forzada por el proveedor.
- Datos dentro de su perímetro — elección del centro de datos, cifrado de los volúmenes según su política interna, sin transferencias de datos entre regiones facturadas en cada lectura analítica.
- Portabilidad total —
pg_dumpo la replicación lógica migran sus datos a cualquier otro host sin fricción de proveedor y sin costos de salida. - Opción de administración disponible — si la carga operativa sigue siendo la objeción principal, la opción de administración del VPS cubre las tareas habituales (actualizaciones, monitorización, copias de seguridad); el control sigue siendo suyo, la carga no.
PostgreSQL en un VPS frente a Amazon RDS: tabla comparativa
Desplace la tabla
| Criterio | PostgreSQL en un VPS | Amazon RDS for PostgreSQL |
|---|---|---|
| Costo mensual (carga de trabajo estándar) | Fijo, proporcional al servidor elegido | Variable: cómputo + almacenamiento + IOPS + Multi-AZ + salidas de red |
| Ejemplo de alta disponibilidad (3 nodos / Multi-AZ) | ~835 $/mes (clúster Hetzner CCX53, mayo de 2026) | ~3 150 $/mes (db.r6g.4xlarge Multi-AZ, us-east-1) |
| Extensiones de PostgreSQL | Todas, incluidas PostGIS, pgvector, TimescaleDB y citus | Lista restringida; extensiones no oficiales ausentes |
| Acceso root / sistema operativo | Sí: elección de OS, Docker, cron, tuning del kernel, pgBouncer | No: solo API de AWS, parámetros restringidos |
| Actualizaciones de versión | A su ritmo, sin ventana de mantenimiento impuesta | Programadas o impuestas por AWS al llegar la obsolescencia |
| Carga operativa | Copias de seguridad, actualizaciones y monitorización a su cargo | Automatizada por AWS: copias de seguridad, parches, failover |
| Portabilidad | Total: `pg_dump` o replicación lógica, sin costos | Ligada al ecosistema de AWS, exportación de datos de pago |
Requisitos previos antes de migrar
Un VPS de 4 GB de RAM y 2 vCPU basta para la mayoría de las bases de datos de aplicaciones web de menos de 50 GB, con tráfico medio y menos de 50 conexiones simultáneas. Para una base más solicitada, un esquema analítico con muchos joins o un servicio expuesto a picos de tráfico, prevea 8 GB de RAM como mínimo. El almacenamiento SSD NVMe es imprescindible: los accesos aleatorios de PostgreSQL sobre un disco mecánico o un SSD SATA de gama baja degradan el rendimiento de forma significativa, sobre todo cuando la caché se vacía tras un reinicio. Se requiere acceso root, algo estándar en cualquier VPS cloud. En la parte de red, necesitará una dirección IPv4 fija o un nombre de dominio interno al que apuntar las conexiones de sus aplicaciones. Prevea, por último, una ventana de migración en la que ambas bases funcionen en paralelo: la aplicación apunta a RDS, usted llena el VPS, verifica la coherencia y después cambia la variable de conexión. La duración depende del volumen: un dump de 5 GB restaurado en paralelo tarda unos minutos; 200 GB pueden tardar varias decenas.
Instalar y configurar PostgreSQL en un VPS
Instalar PostgreSQL desde el repositorio oficial PGDG
En Ubuntu 24.04 o Debian 12, añada el repositorio del PostgreSQL Global Development Group para obtener la versión actual en lugar de la empaquetada por la distribución:
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpgy despuésecho "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list. A continuación:sudo apt update && sudo apt install -y postgresql-17.Crear un usuario y una base de datos dedicados
Conéctese como
postgres:sudo -u postgres psql. Después cree un usuario de aplicación y una base aislada:CREATE USER monapp WITH PASSWORD 'mot-de-passe-fort';seguido deCREATE DATABASE monapp OWNER monapp;. Salga con\q. No utilice nunca el rolpostgresen la cadena de conexión de su aplicación: un fallo o una inyección operaría con permisos de superusuario.Configurar postgresql.conf para la carga prevista
El archivo de configuración se encuentra en
/etc/postgresql/17/main/postgresql.conf. Parámetros clave para un VPS de 4 GB:shared_buffers = 1GB(25 % de la RAM),effective_cache_size = 3GB,work_mem = 16MB,maintenance_work_mem = 256MB,max_connections = 100. Reinicie tras cualquier modificación:sudo systemctl restart postgresql. Para un VPS de 8 GB, subashared_buffersa 2 GB yeffective_cache_sizea 6 GB.Restringir las conexiones de red en pg_hba.conf
Por defecto, PostgreSQL solo escucha en
localhost. Si su aplicación está en el mismo servidor, es perfecto: no modifique nada. Para una aplicación alojada en otra máquina, edite/etc/postgresql/17/main/pg_hba.confy añada:host monapp monapp <IP-application>/32 scram-sha-256. Enpostgresql.conf, pongalisten_addresses = 'localhost,<IP-VPS>'. Recargue:sudo systemctl reload postgresql.Exportar desde RDS e importar en el VPS
Desde una máquina con acceso a ambos hosts, exporte con el formato custom de
pg_dump:pg_dump -h <endpoint-rds> -U <user> -Fc <base> -f dump.pgc. Después importe en el VPS en paralelo con 4 workers:pg_restore -h localhost -U monapp -d monapp -j 4 dump.pgc. Verifique el recuento de filas de algunas tablas críticas antes de cambiar la conexión de la aplicación.Automatizar las copias de seguridad con un cron
Cree
/usr/local/bin/pg-backup.sh:PGPASSWORD='mot-de-passe' pg_dump -U monapp monapp -Fc > /var/backups/pg/monapp-$(date +%Y%m%d-%H%M).pgc. Hágalo ejecutable:chmod +x /usr/local/bin/pg-backup.sh. Añada la línea al crontab:0 3 * * * /usr/local/bin/pg-backup.sh. Conserve los dumps cifrados en un almacenamiento externo o transfiéralos conrsynca un segundo VPS para garantizar una copia fuera del sitio.Activar la supervisión con pg_stat_statements
En
postgresql.conf, añadashared_preload_libraries = 'pg_stat_statements'. Reinicie PostgreSQL y active después la extensión en su base:CREATE EXTENSION pg_stat_statements;. A continuación identifique las consultas lentas:SELECT query, mean_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;. Esto sustituye con ventaja a las métricas de Performance Insights de RDS para el diagnóstico diario.
Endurecimiento posterior a la instalación: desactive la cuenta de sistema postgres para las conexiones SSH (sudo passwd -l postgres); active ssl = on en postgresql.conf con un certificado Let's Encrypt o autofirmado para cifrar las conexiones de red entre la aplicación y la base de datos; active ufw y abra el puerto 5432 únicamente a las IP de aplicación conocidas (sudo ufw allow from <IP-app> to any port 5432). Estos tres gestos cubren lo esencial de la superficie de ataque de una base de datos expuesta en una red no privada.
Resolución de problemas: errores frecuentes tras la migración
Los errores siguientes aparecen con frecuencia en las primeras horas después de migrar de RDS a un VPS autónomo. Cada uno tiene un mensaje preciso y un remedio concreto: lea el mensaje completo antes de actuar, porque varias causas distintas comparten el mismo código de error.
Cinco errores frecuentes y sus soluciones
FATAL: password authentication failed for user "monapp"— la contraseña enviada no coincide con la registrada en la base, o el método de autenticación difiere (md5frente ascram-sha-256). Verifique la línea enpg_hba.confy recargue:sudo systemctl reload postgresql. Si cambió la contraseña desde psql, asegúrese de que la cadena de conexión de la aplicación refleje la nueva.FATAL: no pg_hba.conf entry for host "<IP>", user "monapp", database "monapp", SSL off— la IP de origen de la conexión no está autorizada enpg_hba.conf. Añada la entrada que falta para esa IP y recargue. Si no utiliza SSL, compruebe que la línea empiece porhosty no porhostssl.ERROR: extension "uuid-ossp" does not exist(o cualquier extensión ausente en RDS) — la extensión está disponible en PostgreSQL pero no activada en esa base. Ejecute desde psql:CREATE EXTENSION IF NOT EXISTS "uuid-ossp";. Si la extensión no viene en el paquete, instálela:sudo apt install postgresql-17-<extension>.FATAL: remaining connection slots are reserved for non-replication superuser connections— se ha alcanzadomax_connections. Auméntelo enpostgresql.confy reinicie, o instalepgBouncerpara mutualizar las conexiones: un pool de 10 conexiones reales puede atender a cientos de clientes de aplicación.pg_restore: error: could not execute query: ERROR: role "rdsadmin" does not exist— RDS crea roles internos que no existen en ningún PostgreSQL fuera de AWS. Añada--no-owner --no-privilegesal comandopg_restore:pg_restore --no-owner --no-privileges -h localhost -U monapp -d monapp dump.pgc. Los objetos se importan sin intentar reasignar la propiedad a los roles de RDS.
Lo que esta comparativa no cubre, y lo que conviene saber antes de decidir
El autoalojamiento traslada a su equipo la carga de gestionar las copias de seguridad, las actualizaciones de seguridad y la monitorización. Es un hecho, no un argumento en contra: se evalúa frente al costo ahorrado. Para un desarrollador que trabaja solo o un equipo pequeño sin experiencia operativa, la opción de administración del VPS cubre las tareas habituales —actualizaciones, vigilancia, copias de seguridad verificadas— sin que usted tenga que orquestarlas. RDS sigue siendo pertinente en dos situaciones muy concretas: cuando la resiliencia multirregión es un requisito contractual y no dispone de los recursos para montarla manualmente, y cuando la facturación por consumo resulta realmente ventajosa para una base muy pequeña con poca actividad (un VPS funciona y se factura las 24 horas del día, incluso sin carga). Para todo lo demás —base de tamaño medio, carga de trabajo estable, equipo con un mínimo de competencias de sistemas— las cifras se inclinan claramente del lado del autoalojamiento. Los artículos PostgreSQL en un VPS: instalación y buenas prácticas y PostgreSQL al final de su ciclo de vida: planificar la actualización completan esta guía en el aspecto operativo y en la gestión de las versiones mayores.
