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

> Hébergement serveur dédié pour PostgreSQL : RAM ECC, cache de pages, NVMe local. Offres ECC dès 91,65 $US par 30 jours, crypto, sans KYC.

- URL: https://lumenfer.com/fr/dedicated-server-for-postgresql/
- Dernière mise à jour: 2026-11-01
- Éditeur: Lumenfer (https://lumenfer.com)

Ce que le manuel de PostgreSQL lui-même exige du matériel, quels réglages changer sur une machine que vous louez en entier, et quelles offres conviennent à un primaire, un réplica ou une base de test.

**Réponse rapide — Quel est le meilleur hébergement serveur dédié pour PostgreSQL ?**

Le meilleur hébergement serveur dédié pour PostgreSQL vous donne de la mémoire ECC, assez de RAM pour mettre en cache votre jeu de travail, et des disques NVMe locaux que vous contrôlez. Le manuel de PostgreSQL lui-même suppose de la RAM ECC. Le Lumen 24 (AMD EPYC 9254, 256 GB DDR5 ECC) de **Lumenfer** coûte 356,25 $US par 30 jours, payable en crypto sans KYC. Les offres ECC commencent à 91,65 $US.

## Faits matériels PostgreSQL issus de la documentation officielle

| Attribut | Valeur |
| --- | --- |
| Documentation consultée | PostgreSQL 18 (18.6), le 1er novembre 2026 |
| Erreurs mémoire | PostgreSQL ne s'en protège pas ; le manuel suppose de la RAM ECC ou mieux |
| Sommes de contrôle des données | Activées par défaut ; les images pleine page du WAL sont toujours accompagnées d'une somme de contrôle |
| shared_buffers | Commencez à 25 % de la RAM sur un serveur de base de données dédié ; au-delà de 40 %, cela aide rarement |
| work_mem | 4 MB par défaut, pour chaque opération de tri ou de hachage, pas pour chaque requête |
| Connexions | Un processus serveur par connexion ; max_connections est généralement de 100 |
| Workers parallèles | max_worker_processes et max_parallel_workers valent tous deux 8 par défaut |
| Mémoire Linux | Un overcommit strict (vm.overcommit_memory=2) rend le tueur OOM bien moins probable |
| Offres ECC à Lumenfer | Lumen 6, Lumen 24 et Lumen 32 |
| Stockage à Lumenfer | NVMe uniquement. 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 |
| Sauvegardes | Les sauvegardes ne sont pas incluses : conservez des copies de vos données ailleurs |

## 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é](https://lumenfer.com/fr/ecc-ram-dedicated-server/ "Do I need ECC RAM on a rented dedicated server?") 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](https://lumenfer.com/fr/clickhouse-server-hardware/ "What hardware ClickHouse needs on bare metal").

*Réglages Linux du manuel PostgreSQL 18, section 18.4*

```bash
# 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](https://lumenfer.com/fr/nvme-vs-sata-ssd-dedicated-server/ "How much faster NVMe is than SATA SSD").

## 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é](https://lumenfer.com/fr/how-many-cores-dedicated-server/ "How many CPU cores you need on a rented dedicated server") 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](https://lumenfer.com/fr/pricing/ "Lumenfer bare-metal plans and prices per 30 days").

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

### Offres Lumenfer pour PostgreSQL

| Offre | CPU | Cœurs | Mémoire | Disques | Par 30 jours | Rôle |
| --- | --- | --- | --- | --- | --- | --- |
| Lumen 6 | AMD EPYC 4244P | 6 cœurs / 12 threads | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | Petit primaire de production |
| Lumen 8 | AMD Ryzen 7 9700X | 8 cœurs / 16 threads | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | Réplica, staging, bases CI |
| Lumen 16 | AMD Ryzen 9 9950X | 16 cœurs / 32 threads | 128 GB DDR5 | 2 × 1,92 TB NVMe | $205.27 | Réplica de lecture, copie de reporting |
| Lumen 24 | AMD EPYC 9254 | 24 cœurs / 48 threads | 256 GB DDR5 ECC | 2 × 1,92 TB NVMe | $356.25 | Primaire de production |
| Lumen 32 | AMD EPYC 9354 | 32 cœurs / 64 threads | 384 GB DDR5 ECC | 2 × 3,84 TB NVMe | $749.67 | Grand primaire, reporting intensif |

### Ce que coûtent ailleurs des serveurs comparables à 24 et 32 cœurs

| Serveur | Caractéristiques | Prix par mois |
| --- | --- | --- |
| Lumenfer Lumen 24 | AMD EPYC 9254 (2022, 24 cœurs / 48 threads), 256 GB DDR5 ECC, 2 × 1,92 TB NVMe en RAID 1, 100 TB par mois à 1 Gbit/s, 1 IPv4 et un IPv6 /64 | $356.25 |
| KoDDoS: EPYC-9354-768GB-3.84TB-NVMe-10Gbps-Hong-Kong | AMD EPYC 9354, 32 cœurs / 384 GB / 3,84 TB NVMe | $475.00 |
| Médiane de 7 hébergeurs | Serveurs comparables à 24 cœurs | $999.57 |
| Lumenfer Lumen 32 | AMD EPYC 9354 (2022, 32 cœurs / 64 threads), 384 GB DDR5 ECC, 2 × 3,84 TB NVMe en RAID 1, 150 TB par mois à 1 Gbit/s, 1 IPv4 et un IPv6 /64 | $749.67 |
| MonoVM: EPYC 9354/384/2x3.84TB NVMe | EPYC 9354, 32 cœurs / 384 GB / 2x3840 GB | $999.57 |
| Médiane de 6 hébergeurs | Serveurs 32 cœurs comparables | $1476.45 |

*Prix vérifiés le 30 octobre 2026.*

Hébergeurs payables en crypto sans vérification d'identité à l'inscription ; CPU 2022+, NVMe uniquement, facturation mensuelle. 1 EUR = 1,1172 USD (BCE, 30 octobre 2026). MonoVM accepte la crypto via plusieurs processeurs, dont Cryptomus/Heleket, un processeur que le Royaume-Uni a désigné pour sanctions le 8 octobre 2026.

## 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](https://lumenfer.com/fr/aws-to-bare-metal/ "Should I move from AWS to bare metal servers?").

## Louer un serveur PostgreSQL

Des machines entières avec accès root, facturées par 30 jours, 3 mois, 6 mois ou 12 mois depuis un solde crypto.

| Offre | Quantité | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 cœurs · 32 GB DDR5 | 91,65 $US | 247,45 $US (−10%) | 439,92 $US (−20%) | 769,86 $US (−30%) |
| Lumen 24 | 24 cœurs · 256 GB DDR5 | 356,25 $US | 961,87 $US (−10%) | 1 710 $US (−20%) | 2 992,50 $US (−30%) |
| Lumen 32 | 32 cœurs · 384 GB DDR5 | 749,67 $US | 2 024,10 $US (−10%) | 3 598,41 $US (−20%) | 6 297,22 $US (−30%) |

Dans chaque formule: 2022+ CPU · DDR5 · NVMe uniquement · RAID 1 · IPv4 dédiée · Sans KYC

**Avant de payer**

- Rechargement minimum de 1 $US. Rechargez une fois en crypto, puis achetez n'importe quelle formule depuis votre solde.
- Les crédits de votre solde n'expirent pas et permettent de renouveler n'importe lequel de vos serveurs. Lorsqu'un rechargement est effectué uniquement pour atteindre le minimum, la partie non dépensée est remboursée sur demande dans les 30 jours suivant le paiement, en USDT ou USDC. Le reste d'un solde n'est pas versé, sauf si la loi l'exige.
- Crédité dès que votre paiement a été vérifié sur la blockchain. Délai habituel de confirmation du réseau : BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min · XMR ≈ 20 min

## Hébergement de serveur dédié PostgreSQL : FAQ

### De combien de RAM ai-je besoin pour une base PostgreSQL de 100 GB ?

Visez à garder la partie chaude des données en mémoire. Avec 128 GB ou plus, les 100 GB entiers tiennent dans shared_buffers plus le cache du noyau. Le manuel autorise alors un random_page_cost plus bas, les lectures touchant rarement le disque.

### Puis-je faire tourner PostgreSQL dans Docker sur le serveur ?

Oui. Les huge pages et l'overcommit sont toutefois des réglages de l'hôte, donc configurez-les sur le serveur lui-même, pas dans le conteneur. Stockez le répertoire de données sur le miroir NVMe, pas dans la couche inscriptible du conteneur.

### Quelle image Linux choisir pour PostgreSQL ?

N'importe lequel d'entre eux : Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 et Proxmox VE 9. Choisissez la distribution que votre équipe met déjà à jour. Proxmox VE ne vous convient que si PostgreSQL tourne dans des machines virtuelles.

### Lumenfer gère-t-il ou optimise-t-il PostgreSQL à ma place ?

Non. Vous obtenez root sur une machine entière ; installer, optimiser et mettre à jour PostgreSQL, c'est votre travail. L'équipe s'occupe du matériel, des redémarrages et des réinstallations que vous demandez dans le tableau de bord.

### Puis-je payer un serveur de base de données sans pièce d'identité ?

Sans KYC : nous ne demandons jamais de pièce d'identité, de selfie, de documents, de carte ni de numéro de téléphone. Rechargez en BTC, USDT, USDC, ETH, SOL, LTC, XMR (minimum 1 $US) et commandez depuis le solde. Votre serveur est en service quelques minutes après la confirmation du paiement, et l'attente ne dépasse jamais une heure ; le tableau de bord suit la préparation, puis affiche l'adresse IP dès que la machine tourne.

## Sources

1. [18.4. Gestion des ressources du noyau (overcommit, huge pages)](https://www.postgresql.org/docs/current/kernel-resources.html) — PostgreSQL 18 documentation (read 2026-11-01)
2. [19.4. Consommation des ressources](https://www.postgresql.org/docs/current/runtime-config-resource.html) — PostgreSQL 18 documentation (read 2026-11-01)
3. [19.7. Planification des requêtes (random_page_cost, effective_cache_size)](https://www.postgresql.org/docs/current/runtime-config-query.html) — PostgreSQL 18 documentation (read 2026-11-01)
4. [19.3. Connexions et authentification (max_connections)](https://www.postgresql.org/docs/current/runtime-config-connection.html) — PostgreSQL 18 documentation (read 2026-11-01)
5. [28.1. Fiabilité (write caches, checksums, ECC)](https://www.postgresql.org/docs/current/wal-reliability.html) — PostgreSQL 18 documentation (read 2026-11-01)
6. [28.6. Internes du WAL (WAL sur un disque séparé)](https://www.postgresql.org/docs/current/wal-internals.html) — PostgreSQL 18 documentation (read 2026-11-01)
7. [Chapitre 25. Sauvegarde et restauration](https://www.postgresql.org/docs/current/backup.html) — PostgreSQL 18 documentation (read 2026-11-01)
8. [15.1. Fonctionnement des requêtes parallèles](https://www.postgresql.org/docs/current/how-parallel-query-works.html) — PostgreSQL 18 documentation (read 2026-11-01)
9. [1.2. Fondamentaux de l'architecture (un processus par connexion)](https://www.postgresql.org/docs/current/tutorial-arch.html) — PostgreSQL 18 documentation (read 2026-11-01)
10. [Recommandations d'usage OSS (overcommit)](https://clickhouse.com/docs/operations/tips) — ClickHouse documentation (read 2026-11-01)
11. [EPYC-9354-3.84TB-NVMe-10Gbps](https://koddos.net/clients/store/amd-dedicated-server/epyc-9354-384tb-nvme-10gbps) — KoDDoS (read 2026-10-30)
12. [Serveurs dédiés](https://monovm.com/dedicated-server/) — MonoVM (read 2026-10-30)

---

Lumenfer: Lumenfer loue des serveurs bare-metal de génération actuelle à Amsterdam, Reykjavik, Zurich et Bucarest, payés en crypto sans KYC : pas de pièce d'identité, pas de selfie, pas de documents. Chaque machine dispose d'un CPU lancé en 2022 ou plus récent, de mémoire DDR5 et de disques NVMe, et est louée entière à un seul client avec accès root. Elle est exploitée par DomaineGoat LLC, une société panaméenne qui ignore les notifications DMCA, ne répond que devant la loi panaméenne, autorise les relais de sortie Tor et ne conserve aucun journal. Sur l'engagement de 30 jours, chaque offre est facturée au moins 25 % sous un serveur de génération actuelle équivalent nommé, parmi 13 hébergeurs crypto sans KYC, relevés le 30 octobre 2026.