PostGIS hébergé : quel service choisir ?

Ce qu'on attend d'une base PostGIS hébergée

PostgreSQL est un moteur de base de données libre ; PostGIS est son extension spatiale, elle aussi libre, qui ajoute les types géométrie et géographie, les index spatiaux et des centaines de fonctions d'analyse. Une base PostGIS hébergée, c'est ce couple installé, mis à jour et surveillé par un prestataire, que vous utilisez à distance.

Pour un usage SIG, le besoin est concret : charger des couches depuis QGIS, les éditer à plusieurs, les publier dans un portail cartographique ou un serveur OGC, et ne jamais perdre de données. La vraie question n'est donc pas seulement de trouver un PostgreSQL en ligne, mais de savoir quel service rend ce flux de travail simple au quotidien.

Les services cloud généralistes

Les grands services de PostgreSQL managé proposent tous PostGIS, à activer vous-même par une commande SQL. Ce sont d'excellents produits, conçus d'abord pour des développeurs d'applications, avec des options avancées : réplicas, mise à l'échelle automatique, branches de données.

Disponibilité de PostGIS vérifiée le 09/11/2026 dans la documentation d'Amazon RDS, sur la page des extensions de Supabase et dans la documentation de Neon. Les versions de PostGIS varient selon la version de PostgreSQL choisie. Les prix de ces services dépendent de nombreux paramètres et ne sont pas repris ici : consultez leurs pages officielles.

Cinq critères pour choisir un PostGIS hébergé

• PostGIS disponible et à jour. Vérifiez la version de PostGIS proposée et la façon de l'activer. Sur un service généraliste, c'est à vous de créer l'extension ; sur une base pensée pour le SIG, elle est déjà là.
• Connexion depuis QGIS. QGIS se connecte en direct à PostgreSQL. Il faut une adresse joignable depuis votre poste, des identifiants simples à reprendre, et aucun réseau privé à configurer.
• Connexion chiffrée (SSL). Vos données circulent sur Internet : la connexion doit être chiffrée, sans manipulation compliquée de certificats côté QGIS.
• Taille et dépassement. Que se passe-t-il quand la base est pleine ? Être prévenu tôt, et ne rien perdre, compte plus qu'un grand volume théorique.
• Prix lisible au Go. Un SIG grossit avec ses données. Un prix au Go et par mois se prévoit facilement ; une facturation au temps de calcul, aux entrées-sorties et au transfert demande une estimation plus fine.

Ajoutez à ces cinq critères une question pratique : qui vous répond quand une connexion échoue ? Sur un service généraliste, le support porte sur PostgreSQL en général ; une erreur de projection, un index spatial manquant ou une couche qui ne s'affiche pas dans QGIS restent à votre charge. Un hébergeur tourné vers le SIG connaît ces situations et parle le même langage que vos géomaticiens.

Une base pensée pour le SIG : l'approche LizPack

LizPack, infrastructure géospatiale open source, n'a écrit ni PostgreSQL ni PostGIS : il les héberge et les entretient. Les bases PostgreSQL/PostGIS dédiées sont livrées avec PostgreSQL 17 et PostGIS 3.5, et les extensions hstore, uuid-ossp et pg_trgm déjà installées.

• Chaque base a ses identifiants et une connexion SSL, utilisable depuis QGIS Desktop, pgAdmin, DBeaver ou vos scripts.
• Vous choisissez la taille à la création, de 1 à 10 Go ; la facturation suit ce volume, par Go et par mois.
• Un courriel vous prévient dès 60 % de remplissage, puis à 75, 80, 90 et 95 %.
• Au-delà du quota, vous avez 24 heures pour libérer de l'espace ; ensuite la base est arrêtée, sans qu'aucune donnée soit supprimée.
• Une base reliée à une instance LizPack Map sert ses couches sur la carte, éditables en ligne ; elle se relie aussi à GeoServer Cloud et reçoit les relevés de LizPack Field.

Les plans Basic et Pro comprennent déjà un stockage PostgreSQL/PostGIS lié à l'instance LizPack Map, joignable directement depuis QGIS à partir du plan Pro. Les bases dédiées sont des bases supplémentaires, dimensionnées indépendamment. Le prix courant au Go est affiché sur la page des tarifs.

Mettre en route une base PostGIS hébergée

Quel que soit le service choisi, la mise en route d'un PostGIS hébergé suit le même chemin. Le voici avec une base LizPack, en indiquant ce qui change ailleurs.

1. Créer la base depuis le tableau de bord en choisissant sa taille, entre 1 et 10 Go. Sur un service généraliste, il faut en plus choisir une région, une classe de machine et des règles réseau.
2. Récupérer l'hôte, le port et les identifiants. Sur un service généraliste, vérifiez que l'adresse de votre poste est autorisée à se connecter.
3. Ajouter une connexion PostgreSQL dans QGIS avec ces informations, en mode SSL, et l'enregistrer pour toute l'équipe.
4. Importer vos couches depuis QGIS ou avec l'outil ogr2ogr de GDAL. Sur un service généraliste, créez d'abord l'extension PostGIS dans la base.
5. Relier la base à votre instance LizPack Map pour servir ses couches sur la carte, éditables en ligne.

Pour quitter un service ou en changer, les outils standards de PostgreSQL suffisent : pg_dump exporte la base, pg_restore la recharge ailleurs. C'est l'avantage d'un format ouvert : votre base n'est liée à aucun fournisseur, et vous pouvez faire un essai sans craindre d'être enfermé. Pensez seulement à vérifier que la version de PostGIS de destination est égale ou supérieure à celle d'origine.

Les erreurs de connexion les plus fréquentes depuis QGIS

La plupart des échecs de connexion à une base PostGIS hébergée ont des causes connues. Avant d'ouvrir un ticket, passez cette liste en revue : elle règle la grande majorité des cas, quel que soit le fournisseur.

• Délai dépassé (timeout). Le poste n'atteint pas le serveur. Sur un service généraliste, l'adresse IP de votre poste n'est souvent pas autorisée dans les règles réseau. Au bureau, un pare-feu peut aussi bloquer le port de PostgreSQL : demandez à votre service informatique s'il est ouvert en sortie.
• Échec d'authentification par mot de passe. L'identifiant ou le mot de passe est faux, souvent à cause d'un espace copié en trop ou d'un caractère spécial mal collé. Recopiez-les depuis la source plutôt que de les retaper.
• Base inexistante. Le nom de la base n'est pas celui de l'utilisateur. Vérifiez le champ base de données de la connexion : il doit contenir le nom exact fourni par l'hébergeur.
• Erreur SSL. Le serveur exige une connexion chiffrée et le client ne la demande pas, ou l'inverse. Dans QGIS, le mode SSL se règle dans la fenêtre de connexion ; le mode require chiffre la connexion sans vérifier le certificat, les modes verify-ca et verify-full vérifient aussi l'identité du serveur, mais demandent son certificat d'autorité.
• Couches vides ou absentes. La connexion fonctionne mais aucune couche n'apparaît : la table n'a pas de colonne géométrique enregistrée, ou l'utilisateur n'a pas le droit de lecture sur le schéma. Cochez aussi l'option qui liste les tables sans géométrie si vous cherchez une table attributaire.

Gardez une trace de la configuration qui fonctionne : hôte, port, nom de base, mode SSL. Le jour où un collègue n'arrive pas à se connecter, comparer sa connexion à la vôtre prend une minute.

Système de coordonnées et index spatiaux : deux réglages qui font la vitesse

Une base PostGIS hébergée lente est rarement une question de serveur. Dans la majorité des cas, la cause est un système de coordonnées mal déclaré ou un index spatial manquant. Les deux se règlent en quelques minutes.

• Déclarez le bon SRID. Chaque colonne géométrique porte un code de système de coordonnées (SRID), par exemple 4326 pour les coordonnées géographiques WGS 84. Une colonne déclarée avec un SRID faux s'affiche au mauvais endroit, ou force QGIS à reprojeter à la volée chaque entité. Les fonctions Find_SRID et UpdateGeometrySRID de PostGIS permettent de vérifier et de corriger la déclaration.
• Stockez dans une projection adaptée à vos mesures. Pour calculer des surfaces et des distances en mètres sur un territoire, une projection métrique locale évite les conversions. Gardez le même système pour les tables que vous croisez souvent : une jointure spatiale entre deux SRID différents oblige PostGIS à transformer les géométries.
• Créez un index spatial. Un index GiST sur la colonne géométrique (CREATE INDEX ... USING GIST) permet à PostGIS de ne lire que les entités de la zone affichée. Sans lui, chaque déplacement de la carte parcourt toute la table. QGIS en crée un par défaut lors d'un import, mais les tables chargées par script ou par ogr2ogr avec des options personnalisées en sont parfois dépourvues.
• Mettez à jour les statistiques. Après un gros import, la commande ANALYZE renseigne le planificateur de requêtes sur le contenu de la table. Il choisit alors d'utiliser l'index au lieu d'un parcours complet.

Ces réglages comptent davantage encore quand la base alimente une carte en ligne : chaque visiteur déclenche des requêtes, et un index manquant se paie à chaque affichage.

Protéger les identifiants de la base dans vos projets QGIS

Par défaut, QGIS peut enregistrer le nom d'utilisateur et le mot de passe d'une connexion PostgreSQL en clair dans le fichier du projet. C'est pratique, mais tout fichier .qgs ou .qgz partagé par courriel ou déposé sur un disque commun transporte alors les clés de votre base.

• Utilisez le gestionnaire d'authentification de QGIS. Il stocke les identifiants dans une base locale chiffrée par un mot de passe principal. Le projet ne contient plus qu'une référence à cette configuration, pas le mot de passe.
• Ou un fichier de service PostgreSQL. Le fichier pg_service.conf associe un nom de service à l'hôte, au port et à la base. Le projet référence le service ; chaque poste garde ses propres paramètres.
• Créez des comptes distincts par usage. Un compte en lecture seule pour la consultation, un compte en écriture pour les éditeurs. Si un identifiant fuit, les dégâts restent limités.
• Changez le mot de passe au départ d'un collaborateur, et vérifiez qu'aucun projet partagé ne contient l'ancien en clair.

Pour un projet publié sur le web, la question se pose différemment : c'est le serveur cartographique qui se connecte à la base, avec ses propres identifiants, et les visiteurs n'y ont jamais accès directement. Sur une instance LizPack Map, la liaison entre Lizmap, QGIS Server et PostGIS est livrée déjà configurée.

Sauvegarder et dimensionner un PostGIS hébergé

Un hébergeur protège son infrastructure, mais vos erreurs restent les vôtres : une table supprimée par mégarde ou une mise à jour SQL mal ciblée ne se rattrapent qu'avec une copie. Gardez donc vos propres exports, en plus des protections du fournisseur.

1. Exporter la base au format personnalisé avec pg_dump (option -Fc) : le fichier est compressé et se restaure table par table si besoin.
2. Conserver plusieurs copies datées, au moins une hors de votre poste de travail.
3. Restaurer de temps en temps une copie dans une base de test avec pg_restore, pour vérifier qu'elle est complète.
4. Noter la version de PostgreSQL et de PostGIS de chaque export : une restauration se fait vers une version égale ou plus récente.

Pour la taille, partez du volume réel de vos données, pas de celui des fichiers d'origine : une couche importée dans PostGIS, avec ses index, occupe souvent un volume différent de son Shapefile ou de son GeoPackage. Importez un échantillon représentatif, mesurez la place prise avec la fonction pg_database_size, puis extrapolez avec une marge pour la croissance. Les rasters volumineux trouvent souvent mieux leur place en fichiers servis par un serveur cartographique que dans la base elle-même.

Chez LizPack, la taille d'une base dédiée se choisit de 1 à 10 Go à la création, et les alertes de remplissage vous laissent le temps de réagir avant d'atteindre la limite.

Quand préférer l'un ou l'autre

Un service généraliste convient mieux si votre base sert d'abord une application métier, si vous avez besoin de plusieurs centaines de gigaoctets, de réplicas en lecture, ou si votre organisation est déjà engagée chez un fournisseur cloud. Vous gagnez en puissance ce que vous dépensez en configuration et en suivi de facture.

Une base pensée pour le SIG convient mieux si vos utilisateurs travaillent dans QGIS, si les volumes restent de quelques gigaoctets et si la base doit alimenter une carte en ligne. Pour comparer avec une installation sur votre propre serveur, lisez héberger Lizmap ou l'installer soi-même ; pour le budget global, combien coûte un SIG web open source ; et pour comprendre notre rôle, ce que fait LizPack.

Questions fréquentes