¿Cuál es el mejor hosting de servidores dedicados para PostgreSQL?

¿Por qué PostgreSQL necesita memoria ECC?

PostgreSQL no protege contra errores de memoria: su capítulo de fiabilidad da por hecho que usas RAM ECC de nivel industrial o superior. Las sumas de comprobación de datos protegen las páginas en disco. Están activadas por defecto en PostgreSQL 18. Un bit que cambia en la RAM antes de una escritura sigue llegando al disco con una suma de comprobación válida.

Para una base de datos primaria, la ECC no es un lujo; es el hardware que PostgreSQL espera encontrar. Los planes de Lumenfer con ECC son:

• Lumen 6: AMD EPYC 4244P, 32 GB DDR5 ECC, 91,65 US$.
• Lumen 24: AMD EPYC 9254, 256 GB DDR5 ECC, 356,25 US$.
• Lumen 32: AMD EPYC 9354, 384 GB DDR5 ECC, 749,67 US$.

Los planes Ryzen indican DDR5 estándar. Sirven para réplicas que puedes reconstruir, bases de datos de staging y copias para informes. Nuestra página sobre si necesitas RAM ECC en un servidor alquilado explica la diferencia.

¿Cuánta RAM necesita un servidor PostgreSQL?

Suficiente para shared_buffers más una amplia caché de páginas del kernel, porque PostgreSQL lee a través de ambas. El punto de partida del manual para un servidor de base de datos dedicado es el 25% de la RAM en shared_buffers. Añade que es poco probable que más del 40% funcione mejor, ya que PostgreSQL también se apoya en la caché del sistema operativo.

• shared_buffers. En una máquina de 256 GB, el 25% son 64 GB. Los valores mayores suelen necesitar también un max_wal_size mayor.
• effective_cache_size. Es una estimación del planificador, no una asignación. Ajústalo a shared_buffers más la caché del kernel que usará PostgreSQL. El valor por defecto es 4 GB, demasiado bajo para un servidor grande.
• work_mem. 4 MB por defecto, asignados a cada paso de ordenación o hash. Una consulta compleja ejecuta varios, y muchas sesiones se ejecutan a la vez. El uso total puede ser muchas veces mayor que el ajuste.
• maintenance_work_mem. 64 MB por defecto, lo usan VACUUM y la creación de índices. Súbelo en un servidor grande.

Cuando toda la base de datos cabe en la RAM, el manual dice que puede ser apropiado bajar random_page_cost. Con cientos de gigabytes de DDR5, muchas bases de datos llegan a ese punto.

¿Debo usar huge pages y overcommit estricto para PostgreSQL?

Sí, en un servidor que solo ejecuta PostgreSQL: el manual documenta ambos para Linux. Las huge pages reducen la sobrecarga de los shared_buffers grandes. El overcommit estricto reduce la probabilidad de que el kernel mate al postmaster cuando escasea la memoria.

PostgreSQL te dice cuántas huge pages necesita. Resérvalas y luego configura huge_pages = on para que el servidor se niegue a arrancar sin ellas. El valor por defecto, try, recurre silenciosamente a la alternativa.

Estos ajustes entran en conflicto con ClickHouse, cuya documentación indica que no se desactive el overcommit. Mantén las dos bases de datos en máquinas separadas; consulta hardware de ClickHouse en bare metal.

# strict overcommit; add the same line to /etc/sysctl.conf
sysctl -w vm.overcommit_memory=2

# how many huge pages does this cluster need? (server stopped)
postgres -D $PGDATA -C shared_memory_size_in_huge_pages
# reserve that number, e.g. 3170, then make it permanent in /etc/sysctl.conf
sysctl -w vm.nr_hugepages=3170

# postgresql.conf: refuse to start without huge pages
# huge_pages = on

¿Qué disposición de almacenamiento conviene para PostgreSQL en un servidor alquilado?

Mantén el espejo NVMe y haz de la replicación y los archivos externos tu segunda copia. Los planes de dos discos incluyen el sistema operativo en un espejo RAID 1 por software; pide al soporte antes de la entrega si prefieres RAID 0 o dos discos separados.

El manual dice que el WAL en un disco separado es ventajoso. En un servidor de dos discos, eso significa romper el espejo. Un disco muerto se llevaría por delante los datos o el WAL. En hardware alquilado sin consola, mantendríamos RAID 1.

Las cachés de escritura merecen una comprobación. El manual advierte de que muchos SSD tienen cachés de write-back volátiles, y muchos no respetan los comandos de flush por defecto. Sugiere probar con diskchecker.pl. Pide al soporte el modelo exacto del disco y busca en su hoja de datos la protección ante cortes de energía. Más sobre tipos de disco en NVMe vs SATA SSD en servidores alquilados.

¿Cuántos núcleos de CPU usa PostgreSQL?

Uno por cada conexión activa, más procesos paralelos para las consultas grandes. PostgreSQL inicia un nuevo proceso de servidor por cada conexión. Las consultas transaccionales cortas se ejecutan en un núcleo cada una, así que la velocidad por núcleo determina su latencia. Los escaneos y joins grandes pueden repartirse entre procesos paralelos.

• Conexiones. max_connections suele ser 100. PostgreSQL dimensiona parte de la memoria compartida a partir de ello, así que miles de conexiones inactivas desperdician RAM. Coloca delante un pooler de conexiones.
• Consulta paralela. Los procesos por consulta están limitados por max_parallel_workers_per_gather. Los totales están limitados por max_worker_processes y max_parallel_workers, ambos 8 por defecto. En 24 o 32 núcleos, súbelos para consultas de informes.

Los planes EPYC cambian algo de velocidad por núcleo a cambio de más núcleos y ECC. Nuestra guía sobre cuántos núcleos de CPU necesita un servidor alquilado cubre el equilibrio.

¿Cómo hago copias de seguridad de PostgreSQL en un servidor alquilado?

Ejecuta archivado continuo a un almacenamiento fuera del servidor y mantén una réplica en streaming en otra ciudad. Las copias de seguridad no están incluidas: guarda copias de tus datos en otro sitio. El manual enumera tres enfoques de copia de seguridad: volcados SQL, copias a nivel de sistema de archivos y archivado continuo. Solo el archivado continuo te permite restaurar a un punto en el tiempo.

Ámsterdam (Países Bajos), Reikiavik (Islandia), Zúrich (Suiza) y Bucarest (Rumanía): los cinco planes en las cuatro ciudades, un mismo precio en todas. Un primario en Ámsterdam con una réplica en Reikiavik o Zúrich cuesta exactamente dos planes, nada más.

¿Qué plan de Lumenfer debería elegir para PostgreSQL?

Elige un plan con ECC para el primario y dimensiónalo para que los datos calientes quepan en memoria. Las réplicas y las copias de prueba pueden ir en los planes Ryzen. Todos los planes y plazos están en la página de precios de Lumenfer.

En la comprobación de Lumenfer de 30 October 2026, 95 de 229 planes comparables en hosts de cripto sin KYC indicaban memoria DDR5. Todos los planes de Lumenfer lo hacen, con una CPU de 2022 o más reciente.

¿Es mejor un servidor alquilado que PostgreSQL gestionado?

Te da una máquina entera a un precio fijo, pero te conviertes en el administrador de la base de datos. Los servicios gestionados ejecutan las copias de seguridad, el failover y las actualizaciones por ti. En un servidor alquilado eliges la versión, las extensiones y cada ajuste del kernel, y te encargas tú de esas tareas.

Lumenfer gestiona solo el hardware. Los reinicios, las reinstalaciones y las cancelaciones se solicitan en el panel y las gestiona el equipo; reinstalar borra los discos. Para la migración en sí, lee si conviene dejar AWS por bare metal.