[{"data":1,"prerenderedAt":220},["ShallowReactive",2],{"seo-verification":3,"blog-heberger-postgresql-vps-ma-fr":6,"promo-bar-likely":219},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-heberger-postgresql-vps-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":35,"sections":36,"ctaTitle":162,"ctaBody":163,"ctaButton":164,"ctaUrl":165,"relatedPosts":166},56,"heberger-postgresql-vps",{"fr":10,"en":12,"ar":13,"es":14},"postgresql-on-a-vps-a-reliable-and-controlled-database","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","alojar-postgresql-en-un-vps","PostgreSQL sur VPS : base fiable et contrôlée","Hébergez PostgreSQL sur VPS : configuration prod, sauvegardes pgBackRest, haute disponibilité streaming, comparatif RDS\u002FSupabase\u002FNeon et dépannage OOM.",9,1,false,"2026-04-25T00:00:00+00:00","2026-10-21T15:21:37+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},6,"Bases de données","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":25,"appSlug":34},"postgresql-stack","PostgreSQL est souvent la base de données de confiance des applications métiers, des APIs et des outils d'analyse. Sur un VPS ServOrbit, vous contrôlez la version, le stockage, les sauvegardes et les accès au lieu de payer une base managée au Go. Ce guide couvre les décisions qui comptent — persistance, utilisateurs, réseau, restauration — ainsi que la configuration fine de `postgresql.conf`, les sauvegardes automatisées avec test de restauration, la haute disponibilité en streaming sur deux VPS, et le dépannage des pannes les plus fréquentes en production.",[37,41,51,54,79,94,97,100,153,156,159],{"type":38,"title":39,"body":40},"h2","Pourquoi auto-héberger PostgreSQL sur un VPS","Les bases managées (RDS, Cloud SQL) facturent au Go stocké, aux IOPS et aux connexions, et limitent souvent les extensions disponibles. En déployant PostgreSQL sur votre propre VPS, vous activez `pg_stat_statements`, `PostGIS`, `pgvector` ou `TimescaleDB` sans restriction, vous choisissez votre version exacte (15, 16, 17) et vous gardez vos données dans une juridiction que vous maîtrisez. Un VPS avec disque SSD offre des latences I\u002FO très basses, idéales pour les workloads transactionnels d'une application en production. Vous payez un forfait fixe et prévisible, et vous décidez seul de votre stratégie de réplication, de chiffrement et de rétention des backups.",{"type":42,"title":43,"items":44},"ul","Les bénéfices concrets d'un PostgreSQL auto-hébergé",[45,46,47,48,49,50],"Coût fixe et prévisible : pas de facturation au Go, aux IOPS ni au nombre de connexions actives.","Extensions libres : `pgvector` pour l'IA, `PostGIS` pour le géospatial, `TimescaleDB` pour les séries temporelles.","Contrôle total des sauvegardes : `pg_dump` planifié, `pg_basebackup` ou réplication physique vers un second VPS.","Tuning fin de `postgresql.conf` (shared_buffers, work_mem, WAL) impossible chez la plupart des offres managées.","Souveraineté des données : vos données restent sur une infrastructure que vous choisissez.","Accès superutilisateur réel pour auditer, profiler et optimiser sans ticket support.",{"type":38,"title":52,"body":53},"Prérequis matériels et logiciels","Pour une instance PostgreSQL de développement ou un petit projet en production, prévoyez un VPS avec 2 vCPU, 4 Go de RAM et 40 Go de SSD NVMe : PostgreSQL aime la mémoire pour son cache de pages. Pour une charge plus soutenue (plusieurs centaines de connexions ou jeux de données de plusieurs dizaines de Go), visez 4 vCPU et 8 Go de RAM. Côté logiciel : Ubuntu 22.04 ou 24.04 LTS, Docker Engine et le plugin Docker Compose v2, un nom de domaine pointant vers le VPS (ex : `db.mondomaine.com`) si vous exposez l'accès distant, et un pare-feu `ufw` configuré pour ne laisser passer que le strict nécessaire. Réservez aussi un volume Docker dédié pour `PGDATA` afin de découpler les données du conteneur.",{"type":55,"title":56,"steps":57},"steps","Déployer PostgreSQL avec Docker en production",[58,61,64,67,70,73,76],{"title":59,"body":60},"Préparer le VPS et le pare-feu","Connectez-vous en SSH, mettez à jour le système avec `apt update && apt upgrade -y`, installez Docker via `curl -fsSL https:\u002F\u002Fget.docker.com | sh`. Bloquez le port 5432 depuis l'extérieur avec `ufw deny 5432` : la base ne doit jamais être directement exposée à Internet.",{"title":62,"body":63},"Écrire le docker-compose.yml","Créez un service `postgres:17`, montez un volume nommé sur `\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata`, et définissez `POSTGRES_PASSWORD`, `POSTGRES_DB` et `POSTGRES_USER` via un fichier `.env` jamais commité. Ajoutez `shm_size: 256mb` pour les tris volumineux et une `healthcheck` avec `pg_isready`.",{"title":65,"body":66},"Lancer et initialiser la base","Démarrez avec `docker compose up -d`, vérifiez les logs via `docker compose logs -f postgres`, puis connectez-vous avec `docker compose exec postgres psql -U app -d mabase`. Créez vos rôles applicatifs avec des privilèges minimaux plutôt que d'utiliser le superutilisateur.",{"title":68,"body":69},"Exposer l'accès via un tunnel ou un proxy TLS","Pour un accès distant sécurisé, n'ouvrez jamais 5432 en clair : utilisez un tunnel SSH (`ssh -L 5432:localhost:5432`) ou placez `pgbouncer` derrière un reverse proxy. Activez le SSL côté PostgreSQL avec un certificat Let's Encrypt monté dans le conteneur (`ssl = on` dans `postgresql.conf`).",{"title":71,"body":72},"Tuner la configuration","Ajustez `shared_buffers` à environ 25% de la RAM, `effective_cache_size` à 50-75%, et `work_mem` selon vos requêtes. Activez `pg_stat_statements` pour identifier les requêtes lentes. Utilisez l'outil PGTune comme point de départ.",{"title":74,"body":75},"Automatiser les sauvegardes","Planifiez un `pg_dump` quotidien via une tâche cron sur l'hôte, compressez en `.dump` custom format, et copiez les archives vers un stockage externe. Testez régulièrement la restauration avec `pg_restore` : une sauvegarde non testée n'existe pas.",{"title":77,"body":78},"Se connecter la première fois","pgAdmin n'est pas publié sur Internet : ouvrez un tunnel depuis votre poste (ssh -L 5050:127.0.0.1:5050 root@\u003CIP>) puis http:\u002F\u002F127.0.0.1:5050, et connectez-vous avec admin@local.host et le mot de passe fourni. Ajoutez ensuite votre serveur (« Add New Server ») avec l'hôte db, le port 5432, l'utilisateur postgres et ce même mot de passe.",{"type":55,"title":80,"steps":81},"Configurer postgresql.conf pour la production",[82,85,88,91],{"title":83,"body":84},"shared_buffers : le cache mémoire de PostgreSQL","Définissez `shared_buffers = 25%` de la RAM totale du VPS. Sur 8 Go de RAM, cela donne 2 Go. Ce paramètre contrôle la taille du cache de pages partagé entre tous les processus PostgreSQL — c'est le levier le plus important pour les lectures répétées. Un fichier `postgresql.conf` personnalisé monté via Docker (`-v .\u002Fpostgresql.conf:\u002Fetc\u002Fpostgresql\u002Fpostgresql.conf`) permet d'appliquer ces réglages au démarrage du conteneur.",{"title":86,"body":87},"work_mem et max_connections","Réglez `work_mem` en fonction de vos requêtes de tri et de jointure : 4 à 16 Mo est raisonnable pour une charge mixte. Attention : chaque connexion peut allouer plusieurs fois `work_mem` simultanément, donc multipliez par `max_connections` pour estimer la consommation mémoire maximale. Pour 100 connexions applicatives, `max_connections = 150` (réserve pour les outils de monitoring et les migrations) suffit largement ; au-delà, utilisez `pgbouncer` en mode transaction pour multiplexer les connexions.",{"title":89,"body":90},"Logging et détection des requêtes lentes","Activez `logging_collector = on`, `log_min_duration_statement = \u003Cseuil_ms>` (ms) et `log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u '` pour tracer toutes les requêtes qui dépassent le seuil configuré. Les logs atterrissent dans `pg_log\u002F` à l'intérieur du volume PGDATA. Coupler cette configuration à `pg_stat_statements` (extension à activer dans `shared_preload_libraries`) vous donne une vue agrégée des requêtes les plus coûteuses sans scanner chaque fichier de log.",{"title":92,"body":93},"WAL et checkpoints","Augmentez `wal_buffers` à 16 Mo et `checkpoint_completion_target` à 0.9 pour étaler l'écriture des checkpoints dans le temps. Sur un SSD NVMe, `random_page_cost = 1.1` (au lieu du défaut 4.0) incite le planificateur à choisir les index scans plutôt que les seq scans — un réglage souvent oublié qui change drastiquement les plans d'exécution sur une base volumineuse.",{"type":38,"title":95,"body":96},"Sauvegardes automatiques et stratégie de recovery","Une sauvegarde non testée est une sauvegarde qui n'existe pas. Trois approches complémentaires couvrent des besoins différents.\n\n**`pg_dump` + cron** est le point de départ : simple à mettre en place, il produit un fichier SQL logique restaurable sur n'importe quelle version compatible. Planifiez-le à 3h du matin, compressez avec `--format=custom` (format binaire compressé, restauration sélective par table), et copiez l'archive vers un stockage externe (objet S3-compatible, autre VPS) avec `rclone` ou `scp`. Conservez 7 jours en local et 30 jours en distant.\n\n**`pgBackRest`** va plus loin : il supporte les backups incrémentaux et différentiels, la compression parallèle et la restauration point-in-time (PITR) à partir des archives WAL. C'est la solution recommandée dès que votre base dépasse quelques Go ou que vous avez besoin de revenir à un état précis à la minute près après un `DELETE` accidentel. Il se configure via un fichier `pgbackrest.conf` et s'intègre à un cron ou un timer systemd.\n\n**Test de restauration mensuel** : exécutez régulièrement `pg_restore -d test_restore \u003Cdump>` sur un VPS de test pour vérifier l'intégrité de vos archives. Un script hebdomadaire qui restaure la dernière sauvegarde et vérifie le nombre de tables ou une requête de contrôle suffit à détecter une corruption silencieuse avant qu'elle ne soit critique.",{"type":38,"title":98,"body":99},"Haute disponibilité légère sans Kubernetes","La haute disponibilité PostgreSQL sur VPS n'implique pas nécessairement Patroni ou un cluster Pacemaker complexe. La réplication streaming native couvre la majorité des besoins avec un minimum de configuration.\n\n**Réplication streaming manuelle** : sur le VPS primaire, activez `wal_level = replica`, ajoutez un utilisateur dédié `replicator` dans `pg_hba.conf` et définissez `max_wal_senders = 3`. Sur le VPS secondaire (standby), lancez `pg_basebackup` pour initialiser une copie physique, créez un fichier `standby.signal` et configurez `primary_conninfo` dans `postgresql.conf`. La réplication démarre automatiquement au redémarrage. Avec `hot_standby = on`, la standby accepte les requêtes en lecture seule — parfait pour déporter les rapports et le monitoring.\n\n**Patroni** ajoute la bascule automatique (failover) : il surveille le primaire via une clé dans `etcd`, `Consul` ou `ZooKeeper`, et promeut automatiquement la standby si le primaire devient inaccessible pendant plus de 30 secondes. Sur deux VPS, il suffit d'un `etcd` tiers (VM légère ou service managé) pour le consensus. Patroni est la voie recommandée dès que vous ne pouvez pas tolérer une intervention manuelle de 5 à 15 minutes lors d'une panne.\n\n**Supervision du lag de réplication** : `SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS lag_bytes FROM pg_stat_replication` sur le primaire vous donne le décalage en octets en temps réel. Un lag supérieur à quelques Mo indique une saturation réseau ou une standby surchargée.",{"type":101,"title":102,"columns":103,"rows":109},"comparison","PostgreSQL self-hosted vs RDS vs Supabase vs Neon",[104,105,106,107,108],"Critère","VPS ServOrbit (self-hosted)","AWS RDS PostgreSQL","Supabase (cloud)","Neon (serverless)",[110,116,122,128,133,139,144,149],[111,112,113,114,115],"Coût mensuel (small)","99 DH\u002Fmois (forfait fixe)","~35-70 $\u002Fmois (db.t3.medium)","~25 $\u002Fmois (Pro)","~19 $\u002Fmois (Launch)",[117,118,119,120,121],"Contrôle de postgresql.conf","Total","Partiel (paramètre groups)","Limité","Minimal",[123,124,125,126,127],"Extensions custom","Toutes (pgvector, PostGIS…)","Liste restreinte","pgvector, PostGIS","Limitées",[129,130,131,132,131],"PITR (Point-in-Time Recovery)","Oui avec pgBackRest","Oui (natif)","Oui (Pro+)",[134,135,136,137,138],"Haute disponibilité","Réplication manuelle ou Patroni","Multi-AZ natif","Natif","Multi-région natif",[140,141,142,143,143],"Charge de maintenance","Élevée (DBA requis)","Faible","Très faible",[145,146,147,147,148],"Données hors US","Oui (VPS marocain)","Selon région","US\u002FEU uniquement",[150,151,152,152,152],"Superuser \u002F extensions","Oui","Non",{"type":38,"title":154,"body":155},"Dépannage des problèmes courants en production","**OOM killer tue PostgreSQL** : le signal `OOM` dans `\u002Fvar\u002Flog\u002Fsyslog` (`oom_kill_process`) indique que la mémoire est épuisée. Causes principales : `shared_buffers` trop élevé, `work_mem` mal calibré face au nombre de connexions, ou processus concurrent (Elasticsearch, Node.js) qui consomme tout le swap. Diagnostic : `cat \u002Fproc\u002Fmeminfo | grep -E 'MemFree|Cached|Buffers'` et `ps aux --sort=-%mem | head -10`. Remède : réduire `work_mem`, activer `huge_pages = try` dans `postgresql.conf`, ou upgrader le VPS.\n\n**Connexions épuisées** (`FATAL: sorry, too many clients already`) : `max_connections` est atteint. Court terme : `SELECT count(*), state FROM pg_stat_activity GROUP BY state` pour identifier les connexions idle. Long terme : déployez `pgbouncer` en mode transaction (`pool_mode = transaction`) devant PostgreSQL — il multiplex des centaines de connexions applicatives vers un pool de 20-50 connexions réelles.\n\n**Autovacuum saturé** : des tables avec beaucoup d'`UPDATE` ou de `DELETE` accumulent des tuples morts (`dead tuples`) qui gonflent les tables et ralentissent les scans. `SELECT relname, n_dead_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10` révèle les tables problématiques. Accélérez l'autovacuum en réduisant `autovacuum_vacuum_scale_factor` (ex : 0.01 au lieu de 0.2) pour les tables critiques via `ALTER TABLE ... SET (autovacuum_vacuum_scale_factor = 0.01)`.\n\n**Checkpoints trop fréquents** (`LOG: checkpoint occurring too frequently`) : le WAL se remplit plus vite que `checkpoint_timeout` (défaut 5 min). Augmentez `max_wal_size` (ex : 2-4 Go) et `checkpoint_timeout` à 15-30 min pour espacer les checkpoints sans risquer une perte de données excessive en cas de crash.",{"type":157,"body":158},"tip","Pour une haute disponibilité, déployez un second VPS en réplication physique en streaming (`primary_conninfo` + slot de réplication). Vous obtenez une standby chaude prête à basculer, et vous pouvez y déporter vos requêtes de lecture lourdes (`hot_standby = on`) pour soulager le primaire. Couplé à `pgBackRest` pour des backups incrémentaux différentiels, vous atteignez un RPO de quelques minutes sans dépendre d'un service managé.",{"type":157,"title":160,"body":161},"La documentation officielle","Pour la configuration avancée, les options propres à l'outil et les changements de version, référez-vous à la \u003Ca href=\"https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">documentation officielle de PostgreSQL\u003C\u002Fa>. Ce guide couvre la mise en ligne sur VPS ServOrbit ; la documentation éditeur reste la référence pour les réglages fins.","Déployez votre PostgreSQL en quelques minutes","Lancez un VPS Cloud ServOrbit avec template Docker préconfiguré et SSD : l'environnement idéal pour héberger PostgreSQL sans facturation au Go.","Configurer mon VPS Cloud","\u002Fvps-cloud",[167,185,203],{"id":168,"slug":169,"slugs":170,"title":174,"excerpt":175,"readTime":17,"views":176,"isPinned":19,"noindex":19,"publishedAt":177,"updatedAt":178,"category":179,"categories":180,"featuredImage":30,"bgImage":31,"posterImage":182,"relatedSolution":183},57,"heberger-mysql-vps",{"fr":169,"en":171,"ar":172,"es":173},"hosting-mysql-on-a-vps","استضافة-mysql-على-خادم-vps","alojar-mysql-en-un-vps","Héberger MySQL sur un VPS : guide complet","Installez MySQL 8.4 LTS sur un VPS : prérequis, sécurisation, performances InnoDB, accès distant sécurisé, sauvegardes automatisées et dépannage.",0,"2026-04-24T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[181],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":25,"appSlug":184},"mysql-stack",{"id":186,"slug":187,"slugs":188,"title":192,"excerpt":193,"readTime":194,"views":176,"isPinned":19,"noindex":19,"publishedAt":195,"updatedAt":196,"category":197,"categories":198,"featuredImage":30,"bgImage":31,"posterImage":200,"relatedSolution":201},58,"heberger-redis-vps",{"fr":187,"en":189,"ar":190,"es":191},"hosting-redis-on-a-vps","استضافة-redis-على-خادم-vps","alojar-redis-en-un-vps","Héberger Redis sur un VPS : guide complet","Déployez Redis sur votre VPS Cloud : prérequis RAM\u002FCPU, sécurité (ACL, TLS), persistance RDB\u002FAOF, dépannage et haute disponibilité.",10,"2026-04-23T00:00:00+00:00","2026-09-08T21:59:59+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[199],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-redis-vps-poster.svg",{"categorySlug":25,"appSlug":202},"redis-stack",{"id":204,"slug":205,"slugs":206,"title":210,"excerpt":211,"readTime":212,"views":176,"isPinned":19,"noindex":19,"publishedAt":213,"updatedAt":214,"category":215,"categories":216,"featuredImage":30,"bgImage":31,"posterImage":218,"relatedSolution":30},59,"heberger-mongodb-vps",{"fr":205,"en":207,"ar":208,"es":209},"hosting-mongodb-on-a-vps","استضافة-mongodb-على-خادم-vps","alojar-mongodb-en-un-vps","Héberger MongoDB sur un VPS","Hébergez MongoDB sur votre VPS Cloud : déploiement Docker, replica set, authentification, indexation et sauvegardes maîtrisées.",3,"2026-04-22T00:00:00+00:00","2026-09-08T22:00:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[217],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mongodb-vps-poster.svg",true,1794270729868]