- Alojar Postgres por cuenta propia no es complejo ni riesgoso, y es una opción más barata y con mayor libertad de ajuste de rendimiento que un servicio administrado
- La mayoría de los servicios de bases de datos en la nube operan con una versión apenas modificada de Postgres de código abierto, y la diferencia real está en el nivel de automatización operativa
- En casos reales de operación, Postgres autohospedado maneja de forma estable miles de usuarios y decenas de millones de consultas, con muy poco tiempo de mantenimiento
- Debido al aumento de precio de servicios administrados como AWS RDS, hoy se puede operar directamente un servidor con especificaciones mucho mayores por el mismo costo
- Para equipos medianos cuya gestión de infraestructura no es demasiado compleja, el autohospedaje se convierte en una alternativa realista en costo-eficiencia y rendimiento
El cambio en la narrativa centrada en la nube
- Antes, la mayoría de las empresas operaban sus bases de datos directamente en sus propios servidores, lo que ofrecía una estructura rápida y con poca latencia de red
- Entre las décadas de 1980 y 2000, era común que el servidor de aplicaciones y el servidor de base de datos estuvieran en el mismo equipo físico
- El lanzamiento de Amazon RDS (2009) fue recibido como una propuesta atractiva porque automatizaba respaldos, parches y monitoreo
- Al comienzo, permitía reducir la carga operativa con un costo similar al de un servidor dedicado
- Desde 2015, con la aceleración de la adopción de la nube, se extendió la idea de que gestionar infraestructura directamente era ineficiente
- El modelo en el que AWS se encargaba de la infraestructura y los desarrolladores se enfocaban en la lógica de la aplicación se consolidó como estándar
- En 2025, los precios de RDS han subido de forma importante, al punto de que con el mismo dinero se puede alquilar un servidor dedicado con especificaciones muy superiores
- Ejemplo: una instancia db.r6g.xlarge (4 vCPU, 32GB RAM) cuesta $328 al mes, con lo que es posible alquilar un servidor de 32 núcleos y 256GB de RAM
Cómo están compuestos realmente los servicios administrados
- AWS RDS es, en esencia, Postgres estándar con sistemas de monitoreo y respaldo propios de AWS añadidos encima
- Incluye respaldos basados en snapshots de EBS, gestión de configuración con Chef/Puppet/Ansible, pooling de conexiones con PgBouncer, monitoreo con CloudWatch y scripts de failover automático
- Esta configuración no es técnicamente compleja, y su valor principal está en la automatización operativa y la facilidad del despliegue inicial
- Al migrar desde RDS a autohospedaje con un servidor de especificaciones equivalentes, el rendimiento fue igual o incluso mejor
- Al poder ajustar directamente parámetros restringidos en RDS, se vuelve posible optimizar el rendimiento
Complejidad operativa del autohospedaje
- La migración a un servidor de DigitalOcean con 16 vCPU / 32GB RAM / 400GB de disco tomó unas 4 horas, y después se confirmó una operación estable
- Los productos con alta disponibilidad requieren unos 30 minutos de administración al mes, y los servicios con poco tráfico pueden automatizarse por completo
- Ciclo de mantenimiento regular
- Semanal (10 min): verificación de respaldos, revisión del log de consultas lentas, comprobación de capacidad de disco
- Mensual (30 min): actualizaciones de seguridad, revisión de la política de retención de respaldos, planeación de capacidad
- Trimestral (2 h): actualización de dashboards de monitoreo, optimización de configuración, pruebas de recuperación
- La respuesta ante fallas queda bajo responsabilidad directa, pero RDS también tiene incidentes y al final los desarrolladores igual deben responder
- Al operar directamente, se puede ajustar por cuenta propia el momento de las actualizaciones y las ventanas de riesgo, lo que facilita asegurar la estabilidad
Cuándo el autohospedaje no es adecuado
- Para desarrolladores en etapas iniciales que necesitan crear un prototipo rápido, un servicio administrado resulta más práctico
- En grandes empresas, puede ser más eficiente contar con ingenieros de bases de datos dedicados o delegarlo a la nube para reducir costos de personal
- En industrias reguladas (PCI-DSS, HIPAA, etc.), puede exigirse el uso de plataformas administradas certificadas
Puntos clave de configuración
- Configuración de memoria: hay que ajustar
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem y otros parámetros según el hardware
- Ejemplo: configurar
shared_buffers al 25% de la RAM y effective_cache_size al 75%
- Gestión de conexiones: usar
pgbouncer para configurar connection pooling, con funcionamiento eficiente en entornos Python asyncio
- Se ofrecen ejemplos de configuración básica como
max_connections = 200, log_connections = on
- Ajuste de almacenamiento: en entornos con NVMe SSD, configurar
random_page_cost = 1.1, effective_io_concurrency = 200, etc.
- La velocidad de lectura aleatoria mejora y eso optimiza la planificación de consultas
- Configuración de WAL: ajustar
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9, etc., para equilibrar durabilidad y rendimiento
Conclusión
- No hace falta operar toda la infraestructura directamente, pero Postgres sí entra en una categoría donde el autohospedaje es razonable
- Si hoy se gastan más de $200 al mes en RDS, vale la pena probar mover una base de datos no crítica a un servidor de prueba
- A futuro, la infraestructura podría evolucionar hacia una forma híbrida que mezcle servicios administrados y autohospedaje
- Postgres es visto como un buen candidato para autohospedaje por su alta eficiencia en relación costo-beneficio
4 comentarios
Como el almacenamiento también garantiza 11 nueves, operarlo es tan difícil como usar la nube, por eso se usa la nube jaja
En la práctica, operar un clúster de 3 nodos probablemente no sea tan fácil.
Comentarios en Hacker News
Yo veo el self-hosting como un tema de responsabilidad
Tengo varios productos SaaS alojados por mi cuenta; salen mucho más baratos que AWS y además rinden bastante mejor
Aun así, en proyectos de clientes los convenzo de pagar AWS, porque así puedo trasladar la responsabilidad de la disponibilidad del hardware a otro lado
Cuando el presupuesto es limitado, el costo de RDS pesa bastante. Operar un clúster Galera de 3 nodos en Hetzner por unos pocos dólares resulta mucho más económico
Pero incluso los servicios administrados como Cloudflare o SQS a veces fallan. Al final, la estabilidad perfecta no existe en ningún lado
AWS Aurora Serverless
Cloud SQL, en cambio, suele tener una estructura de costos compleja, y una vez que dejas configurados los backups, listo
No estoy de acuerdo con que el self-hosting sea la opción correcta para la mayoría
Más bien creo que solo tiene sentido alojarlo uno mismo cuando el presupuesto es muy ajustado o cuando la empresa ya es lo suficientemente grande como para tener ingenieros dedicados
Para empresas pequeñas, dejarlo en la nube es lo más realista. Después del setup, con 30 a 120 minutos al mes de administración suele alcanzar
Un PaaS como Heroku o Render sí puede manejarlo un desarrollador generalista, pero sale bastante más caro
Al final, si no tienes automatizada la recuperación de la aplicación, igual te van a despertar a las 3 a. m.
Si es una herramienta interna, agregar un Postgres a Docker toma 5 minutos
La definición de ‘base de datos administrada’ es confusa
Para mí, los requisitos básicos son backups automáticos, optimización de índices, failover multirregión/multidata center, recuperación a un punto en el tiempo, análisis de consultas lentas y predicción de almacenamiento
Si todo eso viene incluido en la tarifa mensual, la discusión sobre self-hosting deja de tener sentido
Al final terminas con dos personas, y como el trabajo se vuelve aburrido, se ponen a intentar mejoras innecesarias y a veces se pierden 6 meses
Las DB administradas son demasiado caras frente a un VPS
Esperaba pagar un extra razonable por la comodidad, pero en la práctica cuestan varias veces más. Por eso no las uso salvo en proyectos grandes
En el artículo falta profundidad en la parte de alta disponibilidad (HA). No se explica con solo hablar de la configuración de WAL. La replicación es costosa
No entiendo por qué Postgres está tan sobrevalorado en HN
No hay una forma sencilla de armar un clúster HA con failover automático como en MongoDB. Me da curiosidad cómo lo resuelven en producción
Discusión relacionada: lista de correo de PostgreSQL
En la práctica, todas las conexiones se cortan, los cachés se reinician y en los upgrades el downtime es inevitable
Oracle RAC es la única excepción, y PostgreSQL no está diseñado así. YugabyteDB es quizá la alternativa más cercana
La mayoría de las apps tolera unas cuantas horas de downtime. Solo las empresas grandes pueden absorber la complejidad de toda esa automatización
Si estás en Kubernetes, CloudNativePG también va bien.
pg_auto_failover es simple, pero tiene limitaciones
Si ves Autobase, automatiza muchas de las tareas necesarias para hacer self-hosting
Llevo 15 años usando Postgres siempre en self-hosted, y casi nunca he tenido problemas
La única preocupación real era hacer la migración de versión de PG para mantenerme al día con los upgrades del ORM. Se pudo resolver con una administración cuidadosa del sistema
Corrí Postgres no administrado directamente en Fly.io y fue una pesadilla
Los nodos morían seguido y tenía que recuperarlos manualmente con repmgr, así que terminé documentando el procedimiento en la wiki interna
Si el objetivo del clúster es la alta disponibilidad, nunca entendí por qué no manejaba automáticamente un primary zombi
Al final migré a Postgres administrado, y se siente muy bien que otra persona se encargue cuando hay incidentes
Muchos comentarios en este hilo ignoran factores reales como escala, carga de trabajo, personal, tiempo, etapa del negocio y requisitos de escalabilidad
Puede que self-hosting sea lo correcto o puede que no; la discusión está demasiado simplificada
Creo que la preocupación de los desarrolladores sería si al hacer self-hosting de algo así se les reconoce ese esfuerzo como tal. Aunque el costo en la nube sea mayor, si no se reconoce el ahorro logrado con self-hosting, al final sale más fácil simplemente usar un servicio cloud y reducir el alcance de lo que uno tiene que cubrir.