[{"data":1,"prerenderedAt":152},["ShallowReactive",2],{"seo-verification":3,"blog-postgresql-haute-disponibilite-patroni-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"slugs":9,"title":12,"excerpt":13,"readTime":14,"views":15,"isPinned":16,"publishedAt":17,"category":18,"categories":24,"featuredImage":26,"bgImage":27,"posterImage":28,"relatedSolution":26,"intro":29,"sections":30,"ctaTitle":103,"ctaBody":104,"ctaButton":105,"ctaUrl":106,"relatedPosts":107},290,"postgresql-haute-disponibilite-patroni-vps",{"fr":8,"en":10,"ar":11},"postgresql-high-availability-with-patroni-on-vps","توافر-postgresql-عال-مع-patroni-على-خادم-vps","PostgreSQL haute disponibilité avec Patroni sur VPS","Cluster PostgreSQL 3 nœuds avec Patroni 4.1 et etcd 3.6 : failover automatique sous 30 secondes, réplication synchrone, sans service managé.",12,0,false,"2026-08-21T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},6,"Bases de données","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[25],{"id":19,"name":20,"slug":21,"color":22,"icon":23},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpostgresql-haute-disponibilite-patroni-vps-poster.svg","Un SaaS multi-tenant ou une application critique ne peut pas se permettre une coupure de base de données. Amazon RDS et Aurora résolvent le problème, mais leur modèle de facturation grandit avec la charge. Patroni 4.1 associé à etcd 3.6 offre le même niveau de disponibilité sur trois VPS avec accès root : failover automatique en moins de 30 secondes, réplication synchrone configurable, et une API REST pour piloter le cluster depuis un terminal. Ce guide couvre l'installation complète, la démonstration du basculement et les opérations quotidiennes.",[31,35,45,48,51,59,87,90,93,97,100],{"type":32,"title":33,"body":34},"h2","Pourquoi la haute disponibilité PostgreSQL sur VPS — et pas RDS","Amazon RDS Multi-AZ résout bien le failover, mais son modèle tarifaire est conçu pour que la facture suive la croissance de façon non linéaire : stockage, IOPS provisionnées, connexions simultanées et la réplication Multi-AZ elle-même se facturent séparément. Pour un SaaS dont la base grossit, le surcoût dépasse vite le coût d'un VPS dédié.\n\nSur trois VPS avec accès root, Patroni assure le même service : un seul leader accepte les écritures, deux répliques synchrones ou asynchrones le suivent, et etcd tient le quorum. Si le leader tombe, Patroni détecte l'absence via le bail etcd (TTL configurable, typiquement 30 secondes) et promeut la réplique la plus à jour. Aucune intervention humaine, aucun DNS à mettre à jour manuellement si un répartiteur de charge comme \u003Ca href=\"\u002Fblog\u002Fdeployer-avec-haproxy-vps\">HAProxy\u003C\u002Fa> pointe vers l'endpoint de santé de Patroni.",{"type":36,"title":37,"items":38},"ul","Ce que ce cluster vous apporte",[39,40,41,42,43,44],"**Failover automatique sous 30 secondes** — Patroni détecte la perte du leader par expiration du bail etcd et promeut sans intervention.","**Réplication synchrone configurable** — `synchronous_mode: true` garantit qu'aucune transaction validée n'est perdue en cas de crash du leader.","**API REST intégrée** — `GET \u002Fleader`, `GET \u002Fhealth`, `POST \u002Fswitchover` : le cluster s'interroge et se pilote sans client PostgreSQL.","**Coût fixe et prévisible** — trois VPS à ressources fixes, sans surprise de facturation liée au trafic.","**Extensions libres** — `pg_hba.conf`, `postgresql.conf`, `pgvector`, `PostGIS` : aucune restriction imposée par un service managé.","**Sauvegardes centralisées** — pgBackRest 2.59 s'intègre nativement avec Patroni pour des sauvegardes incrémentales depuis la réplique.",{"type":32,"title":46,"body":47},"Architecture du cluster : trois nœuds, un quorum","Le cluster repose sur trois couches :\n\n**etcd** tient le registre de configuration distribué (DCS). C'est lui qui détient le bail de leader. Si le leader Patroni ne renouvelle pas ce bail dans le délai TTL, etcd le libère et les standbys se candidatent à l'élection. Avec trois nœuds etcd (un par VPS), le quorum tolère la perte d'un nœud sans perdre la disponibilité.\n\n**Patroni** tourne sur chaque VPS aux côtés de PostgreSQL. Il s'occupe de l'initialisation du cluster, de la configuration de `postgresql.conf` et de `pg_hba.conf`, du suivi du lag de réplication, et du failover. Il expose une API REST sur le port 8008.\n\n**PostgreSQL** est géré entièrement par Patroni — ne pas éditer `postgresql.conf` directement, toute modification passe par `patronictl edit-config` pour rester synchronisée sur les trois nœuds.\n\nLe flux de réplication : le leader reçoit les écritures en WAL, les répliques se connectent via `pg_basebackup` au premier démarrage puis suivent le flux WAL en continu. En mode synchrone, le leader attend la confirmation d'au moins une réplique avant de retourner `COMMIT` au client.",{"type":32,"title":49,"body":50},"Prérequis : ressources et réseau","Ce guide a été écrit avec Patroni 4.1.5, etcd 3.6.6 et PostgreSQL 17 sur Debian 12.",{"type":36,"title":52,"items":53},"Ressources minimales recommandées par nœud",[54,55,56,57,58],"**2 vCPU \u002F 4 Go RAM** — suffisant pour démarrer ; prévoir 8 Go RAM dès que la base dépasse quelques Go de `shared_buffers`.","**SSD NVMe** — la réplication WAL est sensible à la latence d'écriture ; un disque magnétique dégrade le lag de réplication.","**Réseau privé entre les trois nœuds** — la communication etcd-etcd et Patroni-PostgreSQL ne doit pas transiter par Internet.","**IPv4 dédiée** — pour l'accès client externe et le `pg_hba.conf` des répliques.","**NTP synchronisé (chrony) — dérive \u003C 1 s** — etcd refuse le quorum si l'horloge d'un nœud dérive de plus d'une seconde. C'est le piège le plus fréquent sur VPS.",{"type":60,"title":61,"steps":62},"steps","Installation : de zéro au cluster opérationnel",[63,66,69,72,75,78,81,84],{"title":64,"body":65},"Synchroniser l'horloge sur les trois nœuds","Sur chaque nœud, installez et activez `chrony` avant toute autre opération :\n\n```bash\napt install -y chrony\nsystemctl enable --now chronyd\nchronyc tracking\n```\n\nVérifiez que `System time offset` est inférieur à 0,1 seconde. Une dérive supérieure à 1 seconde provoque des timeouts etcd et des élections en boucle.",{"title":67,"body":68},"Installer etcd 3.6 sur les trois nœuds","Définissez les variables d'environnement propres à chaque nœud (remplacez `NODE1_IP`, `NODE2_IP`, `NODE3_IP` par les IP privées) :\n\n```bash\nETCD_VER=v3.6.6\ncurl -L https:\u002F\u002Fgithub.com\u002Fetcd-io\u002Fetcd\u002Freleases\u002Fdownload\u002F${ETCD_VER}\u002Fetcd-${ETCD_VER}-linux-amd64.tar.gz \\\n  | tar xz -C \u002Fusr\u002Flocal\u002Fbin --strip-components=1 etcd-${ETCD_VER}-linux-amd64\u002Fetcd \\\n                                                   etcd-${ETCD_VER}-linux-amd64\u002Fetcdctl\n```\n\nCréez `\u002Fetc\u002Fetcd\u002Fetcd.conf.yml` sur chaque nœud (exemple pour `pg-node1`) :\n\n```bash\nname: pg-node1\ndata-dir: \u002Fvar\u002Flib\u002Fetcd\nlisten-peer-urls: http:\u002F\u002FNODE1_IP:2380\nlisten-client-urls: http:\u002F\u002FNODE1_IP:2379,http:\u002F\u002F127.0.0.1:2379\ninitial-advertise-peer-urls: http:\u002F\u002FNODE1_IP:2380\nadvertise-client-urls: http:\u002F\u002FNODE1_IP:2379\ninitial-cluster: pg-node1=http:\u002F\u002FNODE1_IP:2380,pg-node2=http:\u002F\u002FNODE2_IP:2380,pg-node3=http:\u002F\u002FNODE3_IP:2380\ninitial-cluster-token: pg-cluster-token\ninitial-cluster-state: new\n```\n\nCréez l'unité systemd, activez et démarrez etcd sur les trois nœuds avant de passer à l'étape suivante.",{"title":70,"body":71},"Vérifier le quorum etcd","Sur n'importe quel nœud :\n\n```bash\netcdctl --endpoints=http:\u002F\u002FNODE1_IP:2379,http:\u002F\u002FNODE2_IP:2379,http:\u002F\u002FNODE3_IP:2379 \\\n  endpoint status --write-out=table\n```\n\nAttendez que les trois lignes affichent `IS LEADER` pour l'une et `false` pour les deux autres, et que `ERRORS` soit vide. Si un nœud n'apparaît pas, vérifiez le pare-feu sur les ports 2379 et 2380.",{"title":73,"body":74},"Installer PostgreSQL et Patroni","Sur les trois nœuds :\n\n```bash\n# PostgreSQL depuis le dépôt officiel PGDG\napt install -y curl ca-certificates\ncurl -fsSL https:\u002F\u002Fwww.postgresql.org\u002Fmedia\u002Fkeys\u002FACCC4CF8.asc | gpg --dearmor -o \u002Fetc\u002Fapt\u002Ftrusted.gpg.d\u002Fpostgresql.gpg\necho \"deb https:\u002F\u002Fapt.postgresql.org\u002Fpub\u002Frepos\u002Fapt bookworm-pgdg main\" > \u002Fetc\u002Fapt\u002Fsources.list.d\u002Fpgdg.list\napt update && apt install -y postgresql-17\n\n# Patroni et le driver etcd\npip3 install patroni[etcd3] psycopg2-binary\n```\n\nArrêtez PostgreSQL — Patroni prend en charge l'initialisation du cluster :\n\n```bash\nsystemctl stop postgresql\nsystemctl disable postgresql\n```",{"title":76,"body":77},"Configurer Patroni sur chaque nœud","Créez `\u002Fetc\u002Fpatroni\u002Fpatroni.yml` (exemple pour `pg-node1`) :\n\n```yaml\nscope: pg-cluster\nnamespace: \u002Fservice\u002F\nname: pg-node1\n\nrestapi:\n  listen: NODE1_IP:8008\n  connect_address: NODE1_IP:8008\n\netcd3:\n  hosts: NODE1_IP:2379,NODE2_IP:2379,NODE3_IP:2379\n\nbootstrap:\n  dcs:\n    ttl: 30\n    loop_wait: 10\n    retry_timeout: 10\n    maximum_lag_on_failover: 1048576\n    synchronous_mode: true\n    synchronous_node_count: 1\n    postgresql:\n      use_pg_rewind: true\n      use_slots: true\n      parameters:\n        wal_level: replica\n        hot_standby: \"on\"\n        wal_keep_size: 128MB\n        max_wal_senders: 10\n        max_replication_slots: 10\n\n  initdb:\n    - encoding: UTF8\n    - data-checksums\n\n  pg_hba:\n    - host replication replicator 0.0.0.0\u002F0 scram-sha-256\n    - host all all 0.0.0.0\u002F0 scram-sha-256\n\npostgresql:\n  listen: NODE1_IP:5432\n  connect_address: NODE1_IP:5432\n  data_dir: \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fmain\n  bin_dir: \u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin\n  authentication:\n    replication:\n      username: replicator\n      password: 'VOTRE_MOT_DE_PASSE_REPLICATION'\n    superuser:\n      username: postgres\n      password: 'VOTRE_MOT_DE_PASSE_POSTGRES'\n```\n\nAdaptez `NODE1_IP` pour chaque nœud.",{"title":79,"body":80},"Démarrer Patroni et initialiser le cluster","Créez l'unité systemd `\u002Fetc\u002Fsystemd\u002Fsystem\u002Fpatroni.service` :\n\n```ini\n[Unit]\nDescription=Patroni PostgreSQL HA\nAfter=network.target etcd.service\nRequires=etcd.service\n\n[Service]\nType=simple\nUser=postgres\nExecStart=\u002Fusr\u002Flocal\u002Fbin\u002Fpatroni \u002Fetc\u002Fpatroni\u002Fpatroni.yml\nRestart=on-failure\nRestartSec=5s\n\n[Install]\nWantedBy=multi-user.target\n```\n\nDémarrez d'abord sur `pg-node1` (ce nœud effectue `initdb` et devient leader), puis sur les deux autres avec un délai de quelques secondes :\n\n```bash\nsystemctl daemon-reload\nsystemctl enable --now patroni\n```\n\nSuivez l'initialisation :\n\n```bash\npatronictl -c \u002Fetc\u002Fpatroni\u002Fpatroni.yml list\n```",{"title":82,"body":83},"Vérifier l'état initial du cluster","Sortie attendue après initialisation complète :\n\n```bash\n+ Cluster: pg-cluster (7234567890123456789) +---------+----+-----------+\n| Member    | Host             | Role    | State   | TL | Lag in MB |\n+-----------+------------------+---------+---------+----+-----------+\n| pg-node1  | NODE1_IP:5432    | Leader  | running |  1 |           |\n| pg-node2  | NODE2_IP:5432    | Sync Standby | running |  1 | 0   |\n| pg-node3  | NODE3_IP:5432    | Replica | running |  1 | 0         |\n+-----------+------------------+---------+---------+----+-----------+\n```\n\n`pg-node2` apparaît comme `Sync Standby` : toute transaction validée sur le leader est garantie sur ce nœud avant que le `COMMIT` ne soit retourné au client.",{"title":85,"body":86},"Configurer pg_hba.conf via Patroni","Ne modifiez jamais `pg_hba.conf` directement. Utilisez `patronictl edit-config` pour ajouter des règles d'accès dans la section `pg_hba` — Patroni propage la configuration sur tous les nœuds et recharge PostgreSQL automatiquement :\n\n```bash\npatronictl -c \u002Fetc\u002Fpatroni\u002Fpatroni.yml edit-config\n```\n\nAjoutez vos règles dans le bloc `pg_hba` du YAML. Sur VPS, la règle `host all all 0.0.0.0\u002F0 scram-sha-256` est un point de départ à affiner selon votre réseau privé.",{"type":32,"title":88,"body":89},"Failover et switchover : démonstration","**Failover simulé — arrêt brutal du leader.**\n\nAvant l'arrêt, notez l'état du cluster :\n\n```bash\npatronictl -c \u002Fetc\u002Fpatroni\u002Fpatroni.yml list\n# → pg-node1 est Leader, pg-node2 est Sync Standby\n```\n\nArretez Patroni sur le leader :\n\n```bash\nsystemctl stop patroni   # sur pg-node1\n```\n\nSuivez la promotion sur un des standbys :\n\n```bash\npatronictl -c \u002Fetc\u002Fpatroni\u002Fpatroni.yml list\n# → (après 10 à 30 secondes)\n# pg-node2 : Leader  | running | TL 2\n# pg-node3 : Replica | running | TL 2 | 0 MB\n# pg-node1 : stopped\n```\n\nPatroni attend l'expiration du bail etcd (TTL = 30 s), puis `pg-node2` (le sync standby) acquiert le bail et se promeut. Le délai effectif est typiquement entre 10 et 30 secondes selon la valeur de `loop_wait`.\n\n**Switchover planifié — bascule sans coupure.**\n\nPour une maintenance programmée, préférez `switchover` qui attend que la réplique cible soit à jour avant de basculer :\n\n```bash\npatronictl -c \u002Fetc\u002Fpatroni\u002Fpatroni.yml switchover pg-cluster \\\n  --master pg-node1 --candidate pg-node2\n```\n\nPatroni attend que le lag soit nul, donne le signal de promotion à `pg-node2`, puis `pg-node1` se reconnecte comme réplique. Durée effective : moins de 5 secondes en conditions normales.\n\n**API REST de statut.**\n\nSans client PostgreSQL, interrogez l'état depuis un load balancer ou un script de monitoring :\n\n```bash\ncurl -s http:\u002F\u002FNODE1_IP:8008\u002Fleader    # 200 = c'est le leader\ncurl -s http:\u002F\u002FNODE2_IP:8008\u002Freplica   # 200 = c'est une réplique saine\ncurl -s http:\u002F\u002FNODE1_IP:8008\u002Fhealth    # JSON : state, role, lag\n```\n\nHAProxy peut pointer ses health checks vers `\u002Fleader` et `\u002Freplica` pour acheminer les écritures et les lectures sur les bons nœuds. Voir le guide \u003Ca href=\"\u002Fblog\u002Fdeployer-avec-haproxy-vps\">HAProxy sur VPS\u003C\u002Fa> pour le câblage complet.",{"type":32,"title":91,"body":92},"Opérations quotidiennes","**Sauvegardes avec pgBackRest 2.59.**\n\nInstallez pgBackRest sur les trois nœuds et désignez un dépôt partagé (objet S3, NFS ou répertoire local dédié). La configuration recommandée tire les sauvegardes depuis une réplique pour ne pas charger le leader :\n\n```bash\npgbackrest --stanza=pg-cluster --type=full backup\n```\n\nActivez la compression et les sauvegardes incrémentales quotidiennes dans `pgbackrest.conf` (`repo1-retention-full=7`). Consultez le guide \u003Ca href=\"\u002Fblog\u002Fsauvegardes-restic-vps\">sauvegardes sur VPS\u003C\u002Fa> pour les stratégies complémentaires.\n\n**Monitoring du cluster.**\n\n`patronictl list` donne le lag en Mo par réplique. Alertez dès que le lag dépasse un seuil (exemple : 50 Mo) : cela signale soit une réplique lente, soit un problème réseau. L'endpoint `GET \u002Fpatroni` retourne un JSON complet incluant `xlog_location` et `replication_state`.\n\n**Scaling vertical.**\n\nPour augmenter les ressources d'un nœud : arrêtez Patroni sur ce nœud (il passe en réplique déconnectée), redimensionnez le VPS, redémarrez. Patroni se reconnecte et rattrape le lag automatiquement via `pg_rewind` ou `pg_basebackup` selon l'amplitude du décalage.\n\n**Trade-off `synchronous_commit`.**\n\nAvec `synchronous_mode: true`, chaque `COMMIT` attend la confirmation du sync standby. Sur un réseau privé local, chaque `COMMIT` attend la confirmation du standby synchrone — le délai dépend de la latence réseau entre nœuds (vérifiez `pg_stat_replication.replay_lag`). Sur un réseau plus large (nœuds dans des datacenters différents), cette latence peut impacter les applications à écritures intensives. Dans ce cas, basculer en `synchronous_mode: false` + réplication asynchrone : vous perdez la garantie de zéro perte de données en cas de crash, mais les écritures restent rapides. C'est un arbitrage à documenter explicitement dans votre configuration.",{"type":94,"title":95,"body":96},"tip","Durcissement : TLS mutual auth entre nœuds","Par défaut, la communication etcd et les connexions de réplication PostgreSQL circulent en clair sur le réseau privé. Sur un réseau partagé ou dans un environnement multi-tenant, activez le TLS mutual auth.\n\nPour etcd, générez une CA et des certificats par nœud, puis ajoutez dans `etcd.conf.yml` :\n\n```yaml\nclient-transport-security:\n  cert-file: \u002Fetc\u002Fetcd\u002Ftls\u002Fserver.crt\n  key-file: \u002Fetc\u002Fetcd\u002Ftls\u002Fserver.key\n  trusted-ca-file: \u002Fetc\u002Fetcd\u002Ftls\u002Fca.crt\n  client-cert-auth: true\npeer-transport-security:\n  cert-file: \u002Fetc\u002Fetcd\u002Ftls\u002Fpeer.crt\n  key-file: \u002Fetc\u002Fetcd\u002Ftls\u002Fpeer.key\n  trusted-ca-file: \u002Fetc\u002Fetcd\u002Ftls\u002Fca.crt\n  peer-client-cert-auth: true\n```\n\nPour la réplication PostgreSQL, utilisez `sslmode=verify-full` dans les paramètres de connexion `primary_conninfo` de Patroni. Le certificat du leader est ainsi vérifié par chaque réplique.",{"type":32,"title":98,"body":99},"Dépannage : les cinq erreurs les plus fréquentes","**1. Quorum etcd perdu — le cluster refuse d'élire un leader.**\n\nSymptôme : `patronictl list` affiche tous les nœuds en `running` mais aucun `Leader`. Cause : un nœud etcd est inaccessible et le quorum (2 sur 3) n'est plus atteint. Vérifiez avec `etcdctl endpoint status` — le nœud défaillant apparaît sans réponse ou avec une erreur de connexion. Corrigez le nœud ou retirez-le provisoirement du cluster (`etcdctl member remove`).\n\n**2. Dérive NTP — élections en boucle.**\n\nSymptôme : le leader change toutes les 30 secondes, les logs Patroni affichent `failed to update leader key`. Cause : l'horloge d'un nœud dérive de plus d'une seconde. Vérifiez avec `chronyc tracking` sur chaque nœud et corrigez avant de redémarrer Patroni.\n\n**3. Split-brain potentiel — `pg_rewind` refuse de s'appliquer.**\n\nSymptôme : un ancien leader redémarre et Patroni refuse de le réintégrer comme réplique, avec l'erreur `could not connect to the target server: pg_rewind target server must be in standby mode`. Le serveur a continué à écrire après la perte du bail. Solution : `pg_rewind --target-pgdata=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fmain --source-server='host=NEW_LEADER_IP ...'`, puis redémarrez Patroni.\n\n**4. Connexion peer rejetée — `pg_hba.conf` manquant.**\n\nSymptôme : la réplication s'initialise mais échoue avec `FATAL: no pg_hba.conf entry for replication connection`. La règle `host replication replicator 0.0.0.0\u002F0 scram-sha-256` n'est pas présente dans la section `pg_hba` du `patroni.yml`. Ajoutez-la via `patronictl edit-config` — pas directement dans `pg_hba.conf`.\n\n**5. Lag persistant après failover — `max_wal_senders` insuffisant.**\n\nSymptôme : la réplique affiche un lag qui ne diminue pas après promotion. Cause fréquente : `max_wal_senders` est trop bas (valeur par défaut de 10 sur certaines versions) et le slot de réplication est saturé. Augmentez à 20 via `patronictl edit-config` (paramètre `max_wal_senders`) et rechargez.",{"type":32,"title":101,"body":102},"Un cluster qui s'administre, pas qui s'improvise","Patroni 4.1 avec etcd 3.6 couvre l'essentiel de ce qu'un service managé apporte sur la disponibilité : élection automatique, réplication synchrone, API de pilotage. La différence, c'est la maîtrise : accès root, extensions libres, coût fixe, et la possibilité de debugguer le nœud qui vacille au lieu d'attendre un support tiers.\n\nLe prérequis opérationnel n'est pas la complexité de Patroni — la procédure ci-dessus le montre. C'est la discipline sur trois points : NTP synchronisé, sauvegardes vérifiées régulièrement, et un runbook de failover testé avant que la panne arrive.\n\nPour démarrer, un cluster Patroni 3 nœuds demande trois VPS avec accès root, IPv4 dédiée et réseau privé. Voir le guide d'installation de base \u003Ca href=\"\u002Fblog\u002Fheberger-postgresql-vps\">PostgreSQL sur VPS\u003C\u002Fa> et le comparatif \u003Ca href=\"\u002Fblog\u002Fpostgresql-self-hosted-vs-rds\">auto-hébergé vs Amazon RDS\u003C\u002Fa> pour choisir l'approche qui correspond à votre charge.","Trois VPS pour un cluster Patroni","Un cluster PostgreSQL Patroni 3 nœuds demande trois VPS avec accès root, IPv4 dédiée et réseau privé. Tous les templates VPS ServOrbit livrent un accès root complet et un réseau privé entre instances.","VPS Cloud ServOrbit","\u002Fvps-cloud",[108,124,139],{"id":109,"slug":110,"slugs":111,"title":114,"excerpt":115,"readTime":116,"views":15,"isPinned":16,"publishedAt":117,"category":118,"categories":119,"featuredImage":26,"bgImage":27,"posterImage":121,"relatedSolution":122},56,"heberger-postgresql-vps",{"fr":110,"en":112,"ar":113},"postgresql-on-a-vps-a-reliable-and-controlled-database","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","PostgreSQL sur VPS : base fiable et contrôlée","Hébergez PostgreSQL sur VPS : volumes, sauvegardes, accès réseau limité et configuration saine pour vos applications.",4,"2026-04-25T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[120],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":21,"appSlug":123},"postgresql-stack",{"id":125,"slug":126,"slugs":127,"title":130,"excerpt":131,"readTime":132,"views":133,"isPinned":16,"publishedAt":134,"category":135,"categories":136,"featuredImage":26,"bgImage":27,"posterImage":138,"relatedSolution":26},239,"postgresql-self-hosted-vs-rds",{"fr":126,"en":128,"ar":129},"self-hosted-postgresql-vs-amazon-rds-roi-comparison","postgresql-sur-vps-vs-amazon-rds-مقارنة-التكلفة-2026","PostgreSQL auto-hébergé vs Amazon RDS : le comparatif ROI","Coût réel de PostgreSQL sur VPS vs Amazon RDS en 2026 : chiffres, configuration, dépannage et guide de migration.",9,2,"2026-08-09T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[137],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fpostgresql-self-hosted-vs-rds-poster.svg",{"id":140,"slug":141,"slugs":142,"title":145,"excerpt":146,"readTime":116,"views":15,"isPinned":16,"publishedAt":147,"category":148,"categories":149,"featuredImage":26,"bgImage":27,"posterImage":151,"relatedSolution":26},225,"postgresql-fin-de-vie-planifier-montee-version",{"fr":141,"en":143,"ar":144},"postgresql-end-of-life-plan-your-major-upgrade","postgresql-ونهاية-الدعم-تخطيط-الترقية-الكبرى","PostgreSQL en fin de vie : planifier la montée de version","PostgreSQL suit chaque version majeure cinq ans, jusqu'à un arrêt en novembre. Repérez la vôtre et planifiez la montée sans perdre de données.","2026-08-05T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[150],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fpostgresql-fin-de-vie-planifier-montee-version-poster.svg",1787580985121]