Quel est le meilleur hébergement serveur dédié pour PostgreSQL ?

Pourquoi PostgreSQL a-t-il besoin de mémoire ECC ?

PostgreSQL ne protège pas contre les erreurs mémoire : son chapitre sur la fiabilité part du principe que vous utilisez de la RAM ECC de qualité industrielle ou mieux. Les checksums de données protègent les pages sur disque. Ils sont activés par défaut dans PostgreSQL 18. Un bit qui bascule en RAM avant une écriture arrive quand même sur disque avec un checksum valide.

Pour une base de données primaire, l'ECC n'est pas un luxe ; c'est le matériel que PostgreSQL a été écrit pour attendre. Les offres Lumenfer avec ECC sont :

• 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.

Les offres Ryzen affichent de la DDR5 standard. Elles conviennent aux réplicas que vous pouvez reconstruire, aux bases de staging et aux copies de reporting. Notre page sur la nécessité de RAM ECC sur un serveur loué explique la différence.

De combien de RAM un serveur PostgreSQL a-t-il besoin ?

Assez pour shared_buffers plus un large cache de pages du noyau, car PostgreSQL lit à travers les deux. Le point de départ du manuel pour un serveur de base de données dédié est 25 % de la RAM dans shared_buffers. Il ajoute que plus de 40 % n'a probablement pas d'intérêt, PostgreSQL s'appuyant aussi sur le cache du système d'exploitation.

• shared_buffers. Sur une machine de 256 GB, 25 % font 64 GB. Les valeurs plus grandes nécessitent généralement un max_wal_size plus grand aussi.
• effective_cache_size. Une estimation du planificateur, pas une allocation. Réglez-la sur shared_buffers plus le cache du noyau que PostgreSQL utilisera. La valeur par défaut est 4 GB, bien trop basse pour un gros serveur.
• work_mem. 4 MB par défaut, accordés à chaque étape de tri ou de hachage. Une requête complexe en exécute plusieurs, et de nombreuses sessions tournent en même temps. L'usage total peut atteindre plusieurs fois le réglage.
• maintenance_work_mem. 64 MB par défaut, utilisé par VACUUM et les constructions d'index. Augmentez-le sur un gros serveur.

Quand la base de données entière tient en RAM, le manuel indique que baisser random_page_cost peut être approprié. Avec des centaines de gigaoctets de DDR5, beaucoup de bases atteignent ce point.

Dois-je utiliser des huge pages et un overcommit strict pour PostgreSQL ?

Oui, sur un serveur qui ne fait tourner que PostgreSQL : le manuel documente les deux pour Linux. Les huge pages réduisent la surcharge pour de grands shared_buffers. L'overcommit strict diminue le risque que le noyau tue le postmaster quand la mémoire manque.

PostgreSQL vous indique combien de huge pages il lui faut. Réservez-les, puis réglez huge_pages = on pour que le serveur refuse de démarrer sans elles. La valeur par défaut, try, effectue un repli silencieux.

Ces réglages entrent en conflit avec ClickHouse, dont la documentation déconseille de désactiver l'overcommit. Gardez les deux bases de données sur des machines séparées ; voir le matériel 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

Quelle organisation de stockage convient à PostgreSQL sur un serveur loué ?

Gardez le miroir NVMe et faites de la réplication et des archives hors site votre seconde copie. Les offres à deux disques sont livrées avec le système d'exploitation sur un miroir RAID 1 logiciel ; demandez au support avant la livraison si vous préférez un RAID 0 ou deux disques séparés.

Le manuel indique que le WAL sur un disque séparé est avantageux. Sur un serveur à deux disques, cela signifie casser le miroir. Un disque mort ferait alors tomber soit les données, soit le WAL. Sur du matériel loué sans console, nous garderions le RAID 1.

Les caches d'écriture méritent une vérification. Le manuel avertit que beaucoup de SSD ont des caches write-back volatils, et beaucoup n'honorent pas les commandes flush par défaut. Il suggère de tester avec diskchecker.pl. Demandez au support le modèle exact du disque, puis cherchez la protection contre les coupures de courant dans sa fiche technique. Plus de détails sur les types de disques dans NVMe vs SATA SSD sur serveurs loués.

Combien de cœurs CPU PostgreSQL utilise-t-il ?

Un par connexion active, plus des workers parallèles pour les grosses requêtes. PostgreSQL démarre un nouveau processus serveur pour chaque connexion. Les courtes requêtes transactionnelles tournent sur un cœur chacune, donc la vitesse par cœur fixe leur latence. Les grands scans et jointures peuvent se répartir entre workers parallèles.

• Connexions. max_connections vaut généralement 100. PostgreSQL dimensionne une partie de la mémoire partagée à partir de cette valeur, donc des milliers de connexions inactives gaspillent de la RAM. Placez plutôt un pooler de connexions devant.
• Requête parallèle. Les workers par requête sont plafonnés par max_parallel_workers_per_gather. Les totaux sont plafonnés par max_worker_processes et max_parallel_workers, tous deux à 8 par défaut. Sur 24 ou 32 cœurs, augmentez-les pour les requêtes de reporting.

Les offres EPYC échangent un peu de vitesse par cœur contre plus de cœurs et de l'ECC. Notre guide sur le nombre de cœurs CPU nécessaires à un serveur loué couvre ce compromis.

Comment sauvegarder PostgreSQL sur un serveur loué ?

Lancez une archivage continu vers un stockage hors du serveur, et gardez un réplica en streaming dans une autre ville. Les sauvegardes ne sont pas incluses : conservez des copies de vos données ailleurs. Le manuel liste trois approches de sauvegarde : les dumps SQL, les copies au niveau du système de fichiers et l'archivage continu. Seul l'archivage continu permet une restauration à un instant donné.

Amsterdam (Pays-Bas), Reykjavik (Islande), Zurich (Suisse) et Bucarest (Roumanie) : les cinq plans dans les quatre villes, un seul prix partout. Un primaire à Amsterdam avec un réplica à Reykjavik ou Zurich coûte exactement deux offres, rien de plus.

Quelle offre Lumenfer choisir pour PostgreSQL ?

Prenez une offre ECC pour le primaire et dimensionnez-la pour que les données chaudes tiennent en mémoire. Les réplicas et les copies de test peuvent tourner sur les offres Ryzen. Chaque offre et chaque durée est sur la page tarifaire Lumenfer.

Dans la vérification de Lumenfer sur 30 October 2026, 95 offres comparables sur 229 chez des hébergeurs crypto sans KYC affichaient de la mémoire DDR5. Chaque offre Lumenfer le fait, sur un CPU de 2022 ou plus récent.

Un serveur loué vaut-il mieux qu'un PostgreSQL managé ?

Il vous donne une machine entière à prix fixe, mais vous devenez l'administrateur de la base de données. Les services managés gèrent les sauvegardes, le failover et les mises à jour pour vous. Sur un serveur loué, vous choisissez la version, les extensions et chaque réglage du noyau, et vous assumez ces tâches vous-même.

Lumenfer ne gère que le matériel. Les redémarrages, réinstallations et annulations se demandent dans le tableau de bord et sont traités par l'équipe ; une réinstallation efface les disques. Pour le déménagement lui-même, lisez faut-il quitter AWS pour le bare metal.