PostgreSQL est l’une des bases de données relationnelles les plus robustes du marché. PostGIS, son extension géospatiale, en fait l’un des systèmes les plus puissants pour stocker, interroger et analyser des données géographiques en production. Mais cette puissance a une condition : la configuration par défaut de PostgreSQL n’a pas été conçue pour les charges spatiales. Sur un serveur installé sans tuning, les requêtes sur de grands jeux de données géométriques sont lentes, les index spatiaux sous-utilisés, et les opérations de maintenance pénalisantes. Ce guide couvre les paramètres critiques, les stratégies d’indexation et les pièges les plus courants pour passer d’une installation PostGIS fonctionnelle à une base de données géospatiale vraiment performante.
PostgreSQL + PostGIS : pourquoi la configuration par défaut est inadaptée aux données spatiales
PostgreSQL est livré avec des valeurs de configuration conservatrices, pensées pour fonctionner sur des machines modestes sans connaissance du contexte de déploiement. Sur un serveur dédié avec 32 ou 64 Go de RAM, ces valeurs par défaut laissent l’essentiel des ressources disponibles inutilisées. Le paramètre shared_buffers — qui contrôle la taille du cache partagé de PostgreSQL — est par défaut à 128 Mo. C’est suffisant pour une base applicative légère, très insuffisant pour des tables de géométries complexes qui peuvent atteindre plusieurs dizaines de Go.
La règle de base pour une instance PostgreSQL dédiée à PostGIS est de monter shared_buffers à 25–40 % de la RAM disponible. Sur un serveur de 32 Go, cela donne une valeur entre 8 et 12 Go. Ce réglage seul peut diviser par deux ou trois le temps de certaines requêtes spatiales répétées, en maintenant les blocs de données fréquemment accédés en mémoire plutôt que de les relire depuis le disque à chaque requête. La base de données géospatiale bénéficie directement de ce paramètre sur toutes les opérations de lecture intensive : ST_Intersects sur de larges couches, jointures spatiales, agrégations géométriques.
La version de référence actuelle est PostGIS 3.6.2, sortie en février 2026 pour PostgreSQL 12 à 18, avec GEOS 3.14.1 et le support complet de SFCGAL 2.2 pour les fonctions 3D. Les gains de performance de GEOS 3.14 sur les opérations de type ST_CoverageClean et les calculs d’intersection sont significatifs par rapport aux versions précédentes — une mise à jour qui se justifie en production.
Les paramètres critiques à tuner : shared_buffers, work_mem, max_parallel_workers
Quatre paramètres concentrent l’essentiel du gain de performance atteignable par la configuration sur une instance PostGIS en production.
- shared_buffers (25–40 % de la RAM) : premier levier de cache. À appliquer via ALTER SYSTEM pour persister entre les redémarrages. Nécessite un restart PostgreSQL pour prendre effet.
- work_mem (64 Mo à 256 Mo selon la charge) : mémoire allouée par opération de tri, hachage ou jointure. Attention : ce paramètre est alloué par opération et par connexion simultanée, pas globalement. Sur une instance avec peu de connexions concurrentes et des requêtes spatiales complexes, monter à 256 Mo produit des gains importants. Sur une instance à forte concurrence, rester à 64 Mo et ajuster par session si nécessaire.
- maintenance_work_mem (256 Mo à 1 Go en production) : mémoire utilisée pour les opérations VACUUM, ANALYZE et CREATE INDEX. Monter ce paramètre réduit significativement la durée de construction des index GiST sur de grandes tables géométriques.
- max_parallel_workers_per_gather (2 à 4 selon les cœurs disponibles) : active le parallélisme pour les fonctions spatiales compatibles. ST_Intersects, ST_Contains et les jointures spatiales par index peuvent bénéficier d’un facteur multiplicatif de vitesse x2 ou plus selon la cardinalité des tables.
Exemple de configuration applicable via ALTER SYSTEM sur une instance dédiée de 32 Go :
ALTER SYSTEM SET shared_buffers = ‘8GB’;ALTER SYSTEM SET work_mem = ‘256MB’;ALTER SYSTEM SET maintenance_work_mem = ‘512MB’;ALTER SYSTEM SET max_parallel_workers_per_gather = 4;ALTER SYSTEM SET effective_cache_size = ’24GB’;SELECT pg_reload_conf();
Le paramètre effective_cache_size n’alloue pas de mémoire : il est une indication au planificateur sur la quantité de mémoire disponible pour le cache OS. Le régler à 70–75 % de la RAM totale permet au planificateur de choisir des plans de requête favorisant les index plutôt que les sequential scans sur les grandes tables.
Index spatiaux GiST et CLUSTER : les deux leviers les plus sous-utilisés
L’index spatial est la brique fondamentale de la performance PostGIS. Sans index GiST sur une colonne géométrique, toute requête de filtrage spatial déclenche un sequential scan complet de la table, quelle que soit la sélectivité du filtre. Sur une table de plusieurs millions de géométries, c’est rédhibitoire.
La création d’un index GiST est directe :
CREATE INDEX idx_parcelles_geomON parcellesUSING GIST (geom);
Plusieurs points de configuration sont souvent ignorés en production :
- La résolution de l’index (fillfactor) : pour les tables en lecture intensive avec peu de mises à jour, réduire le fillfactor à 90 réduit la fragmentation de l’index sur le long terme.
- L’index sur les sous-types géométriques : si une colonne contient un mix de types (Point, LineString, Polygon), créer des index partiels par type améliore la sélectivité sur les requêtes mono-type.
- CLUSTER sur l’index GiST : l’opération CLUSTER réorganise physiquement les blocs de la table dans l’ordre de l’index spatial. Elle force les géométries spatialement proches à être stockées dans des blocs disque contigus, ce qui améliore considérablement la localité de cache pour les requêtes de voisinage et les jointures spatiales sur des zones géographiques délimitées.
CLUSTER parcelles USING idx_parcelles_geom;ANALYZE parcelles;
CLUSTER est une opération bloquante qui nécessite un verrou exclusif sur la table. À planifier en maintenance, pas en ligne. Sur des tables fréquemment mises à jour, l’ordre physique se dégrade progressivement : un CLUSTER périodique (mensuel ou trimestriel selon le volume d’écritures) maintient la performance des lectures.
PostGIS 3.x propose également les index SP-GiST comme alternative aux GiST pour certains types de données spatiales (points purs, données non chevauchantes). Sur des distributions de points très denses, SP-GiST peut surpasser GiST sur les requêtes de type KNN (K plus proches voisins). Le choix entre les deux se fait par benchmark sur les requêtes représentatives du workload réel.
Géométries invalides, conversions de dimension et pièges classiques à éviter
Les problèmes de performance PostGIS en production sont souvent liés à des données mal préparées plutôt qu’à un déficit de configuration. Trois catégories de pièges concentrent la majorité des incidents.
Géométries invalides
Une géométrie invalide au sens OGC (auto-intersection, anneau non fermé, polygone dégénéré) provoque des comportements imprévisibles dans les fonctions spatiales : résultats incorrects silencieux, erreurs d’exécution, ou performances dégradées sur certaines versions de GEOS. Le diagnostic systématique avant indexation :
SELECT id, ST_IsValidReason(geom)FROM parcellesWHERE NOT ST_IsValid(geom);
La correction s’effectue via ST_MakeValid (PostGIS 2.0+), qui tente de réparer les géométries sans les supprimer. ST_MakeValid avec l’option ‘method=structure’ (PostGIS 3.1+) est plus conservatrice sur la forme originale que le comportement par défaut.
Conversions de SRID implicites
Croiser deux couches dans des systèmes de projection différents sans reprojection explicite force PostgreSQL à effectuer une conversion à la volée pour chaque paire de géométries comparées. Sur des jointures spatiales à grande échelle, le coût de ces conversions implicites est considérable. La règle : toujours travailler dans un SRID homogène au niveau de la base, et documenter les SRIDs dans le catalogue via geometry_columns. La vérification :
SELECT f_table_name, f_geometry_column, srid, typeFROM geometry_columnsWHERE f_table_schema = ‘public’;
ST_Transform et requêtes répétitives
Si une reprojection est nécessaire dans des requêtes fréquentes, matérialiser la géométrie reprojetée dans une colonne dédiée avec son propre index GiST est toujours plus performant que de calculer ST_Transform à la volée. Le surcoût en stockage est négligeable par rapport au gain en temps d’exécution sur des requêtes répétées.
PostGIS dans les architectures hybrides 2026
PostGIS n’est pas une technologie isolée en 2026. Il s’intègre de plus en plus dans des architectures hybrides où il coexiste avec DuckDB (analyse OLAP locale sur données géospatiales via l’extension spatial), Apache Sedona (traitement distribué de données spatiales sur Spark) et les cloud warehouses (BigQuery Geography, Snowflake Geometry). La stratégie courante est de maintenir PostGIS comme backend transactionnel et de référence, en déversant les analyses à grande échelle vers DuckDB ou Sedona selon la volumétrie. Cette architecture tire le meilleur de chaque composant sans chercher à faire de PostGIS un moteur de traitement distribué qu’il n’est pas conçu pour être.
