Serveur cloud pour PostgreSQL en Europe
PostgreSQL est la base de données de choix pour les applications qui nécessitent fiabilité, requêtes complexes et integrite des données stricte. Si vos utilisateurs ou votre entreprise sont en Europe, exécuter PostgreSQL sur un serveur cloud EU n'est pas seulement une preference technique - c'est une nécessite légale en vertu du RGPD.
Pourquoi la résidence des données en EU compte pour PostgreSQL
Le RGPD exige que les données personnelles des residents de l'UE soient traitees sous juridiction européenne. Héberger votre base de données PostgreSQL sur un serveur physiquement situe dans l'UE et exploite par une entreprise européenne satisfait les exigences de résidence des données sans accords complexes avec les hyperscalers americains.
De plus, les serveurs EU offrent une latence plus faible pour les utilisateurs européens. Une base de données a Francfort ou Prague répond 30-80 ms plus vite a une application berlinoise qu'une hebergee en Virginie.
Specifications minimales pour PostgreSQL
- Petit (dev/staging) - 4 vCPU, 8 Go RAM, 100 Go NVMe SSD
- Moyen (app de production) - 8 vCPU, 32 Go RAM, 500 Go NVMe SSD
- Grand (analytique ou OLTP a écriture intensive) - 16+ vCPU, 64-128 Go RAM, 1+ To NVMe SSD
Configuration DCXV recommandée
Les serveurs cloud DCXV fonctionnent sur une infrastructure certifiee Tier III dans l'UE avec stockage NVMe. Une configuration de production PostgreSQL pratique sur DCXV:
- 8 vCPU, 32 Go RAM, 500 Go NVMe - gere la plupart des bases de données SaaS de production
- 16 vCPU, 64 Go RAM, 1 To NVMe - bases de données analytiques avec requêtes de reporting concurrentes
Contactez sales@dcxv.com pour une recommandation de configuration.
Commandes de configuration rapide
# Installer PostgreSQL 16 sur Ubuntu 22.04
sudo apt update && sudo apt install -y postgresql-16
# Démarrer et activer le service
sudo systemctl start postgresql
sudo systemctl enable postgresql
# Créer une base de données et un utilisateur
sudo -u postgres psql -c "CREATE DATABASE myapp;"
sudo -u postgres psql -c "CREATE USER myapp_user WITH ENCRYPTED PASSWORD 'strongpassword';"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE myapp TO myapp_user;"
# Paramètres clés postgresql.conf pour 32 Go RAM
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 64MB
maintenance_work_mem = 2GB
max_connections = 200
Ce que fait réellement chaque paramètre de mémoire
Les quatre valeurs de ce bloc de configuration ne sont pas arbitraires, et une seule est une limite par serveur. Confondre cette différence est la raison pour laquelle une machine dotée de beaucoup de RAM finit par utiliser le swap:
| Paramètre | Ce qu'il couvre | Valeur ci-dessus | Comment vous voyez qu'il est faux |
|---|---|---|---|
| shared_buffers | Le cache de pages partagé, une fois par serveur | 8 Go | Les lectures continuent d'aller au disque alors que la mémoire libre reste inutilisée |
| work_mem | Un tri ou un hachage, par opération | 64 Mo | Des fichiers temporaires apparaissent dans le journal, ou le serveur swappe sous charge |
| maintenance_work_mem | VACUUM et construction d'index, par worker | 2 Go | Autovacuum ne termine jamais sur la plus grande table |
| effective_cache_size | Rien - c'est une indication pour le planificateur | 24 Go | Le planificateur choisit un parcours séquentiel plutôt qu'un très bon index |
work_mem est celui qui fait mal. Il s'applique par tri, pas par connexion, donc une requête avec trois tris sur cinquante connexions peut demander cent cinquante fois la valeur définie. Augmentez-le pour la seule requête de reporting qui en a besoin, dans sa session, et non pour tout le serveur.
Performances attendues
Sur une instance de 8 vCPU / 32 Go RAM / NVMe avec PostgreSQL 16:
- pgbench TPS (lecture seule) - 12 000-18 000 TPS
- pgbench TPS (lecture-écriture) - 4 000-7 000 TPS
- Latence de recherche d'une ligne (avec index) - moins de 0,5 ms
Ce sont des attentes pour du matériel de cette classe, pas des mesures issues de notre propre laboratoire. Prenez-les comme point de départ pour le dimensionnement et mesurez votre charge : les chiffres réels dépendent de vos données, de vos requêtes et de votre tuning bien plus que du fournisseur.
PostgreSQL tourne rarement seul. Pour budgéter la mémoire de la base à côté de l'API, du worker et du cache, voir Dimensionner un serveur cloud pour un SaaS, un exemple détaillé sous Docker Compose.
Conclusion
PostgreSQL sur un serveur cloud EU vous offre la conformité RGPD, une faible latence pour les utilisateurs européens et un contrôle total sur vos données.
