PostgreSQL extensions essentielles 2026 : pgvector, PostGIS, TimescaleDB

PostgreSQL est puissant tout seul, mais avec ses extensions il devient incomparable : pgvector pour l’IA et la recherche sémantique, PostGIS pour le géographique, pg_stat_statements pour le monitoring, TimescaleDB pour les séries temporelles, Citus pour le sharding. Voici le guide des extensions essentielles en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer).

Ce guide général couvre les extensions principales. Les articles connexes détaillent : pgvector pour RAG IA, PostGIS cartographie, pg_stat_statements monitoring, TimescaleDB séries temporelles.

Extensions essentielles 2026

pgvector — recherche sémantique IA

Stocke des vecteurs (embeddings de texte/image) et permet la recherche par similarité. Indispensable pour RAG, recommandation, déduplication intelligente.

CREATE EXTENSION vector;

CREATE TABLE docs (
  id serial PRIMARY KEY,
  content text,
  embedding vector(1536)
);

CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- Top 5 documents les plus proches
SELECT content
FROM docs
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 5;

Voir notre tutoriel pgvector RAG.

PostGIS — données géographiques

Standard mondial pour SQL géographique. Tracker localisation utilisateurs, calculer distances, zones, routes.

CREATE EXTENSION postgis;

CREATE TABLE clients (
  id serial PRIMARY KEY,
  name text,
  location geography(POINT, 4326)
);

-- Clients dans un rayon de 5 km autour de Dakar
SELECT name FROM clients
WHERE ST_DWithin(
  location,
  'POINT(-17.4441 14.6928)'::geography,
  5000
);

Voir notre tutoriel PostGIS.

pg_stat_statements — monitoring requêtes

Indispensable pour identifier les requêtes lentes en production. Voir notre tutoriel monitoring.

TimescaleDB — séries temporelles

Optimisé pour stocker des millions de points temporels (IoT, métriques, logs structurés). Voir notre tutoriel TimescaleDB.

Autres utiles

• uuid-ossp : génération UUID v1, v4, v5
• pgcrypto : hashage, chiffrement
• citext : texte case-insensitive
• hstore : key-value
• pg_trgm : recherche full-text simple, ILIKE accéléré
• btree_gin : indexation combinée

Activer une extension

# Sur l'image Docker postgres officielle
# Certaines extensions sont déjà incluses (uuid-ossp, pgcrypto, hstore, pg_trgm)

# Pour pgvector, PostGIS, TimescaleDB : utiliser images spécialisées
docker run -d \
  --name pg-vector \
  -e POSTGRES_PASSWORD=secret \
  pgvector/pgvector:pg16

# Puis dans psql :
CREATE EXTENSION IF NOT EXISTS vector;

Adaptation Afrique de l’Ouest

PostGIS particulièrement utile pour les apps de logistique, livraison, services à domicile en Afrique de l’Ouest. pgvector pour les agents IA métier custom (FAQ intelligente, recherche catalogue produits).

Pour étoffer le tableau

• pgvector RAG
• PostGIS
• pg_stat_statements
• TimescaleDB
• PostgreSQL Coolify

Étape 1 : choisir les extensions selon votre cas d’usage

PostgreSQL 17 supporte plus de 200 extensions, mais 90 % des projets ouest-africains que nous accompagnons n’en activent que trois ou quatre. Avant d’installer quoi que ce soit, posez la question métier. Vous faites de la recherche sémantique sur des FAQ ou des fiches produits ? pgvector. Vous gérez des points de livraison Yango ou des zones de couverture mobile money ? PostGIS. Vous stockez des métriques IoT ou des logs applicatifs avec dimension temporelle ? TimescaleDB. Vous avez besoin de recherche plein texte multilingue avec fautes de frappe ? pg_trgm. Activer une extension qui ne sert pas augmente la surface d’attaque et complique les sauvegardes.

Étape 2 : installer pgvector 0.8

pgvector v0.8 (publié fin 2025) ajoute le type halfvec pour réduire de 50 % l’empreinte mémoire des index HNSW, et améliore la précision des recherches approximatives. Sur Debian 12 / Ubuntu 24.04 :

sudo apt install postgresql-17-pgvector
sudo -u postgres psql -d mydb -c "CREATE EXTENSION vector;"
sudo -u postgres psql -d mydb -c "SELECT extversion FROM pg_extension WHERE extname='vector';"

L’output doit afficher 0.8.0 ou supérieur. Si vous compilez depuis les sources sur un VPS Contabo, prévoyez 2 minutes de build : git clone --branch v0.8.0 https://github.com/pgvector/pgvector.git && cd pgvector && make && sudo make install. Redémarrez PostgreSQL pour que le serveur charge la bibliothèque partagée.

Étape 3 : créer une table avec embeddings

Pour un cas d’usage RAG (FAQ d’une banque togolaise par exemple), créez une table qui stocke chaque réponse avec son embedding 1024 dimensions :

CREATE TABLE faq (
  id bigserial PRIMARY KEY,
  question text NOT NULL,
  answer text NOT NULL,
  embedding vector(1024),
  created_at timestamptz DEFAULT now()
);

CREATE INDEX ON faq USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

Le paramètre m=16 contrôle la connectivité du graphe HNSW (16 voisins par nœud) et ef_construction=64 la qualité de la construction. Pour un dataset de moins de 50 000 lignes, ces valeurs par défaut conviennent. Au-delà de 1 million de lignes, montez à m=32, ef_construction=128 au prix d’un index plus volumineux.

Étape 4 : installer PostGIS pour la géolocalisation

PostGIS 3.5, sorti en octobre 2024, est l’extension de référence pour gérer les coordonnées géographiques. Installation :

sudo apt install postgresql-17-postgis-3
sudo -u postgres psql -d mydb -c "CREATE EXTENSION postgis;"
sudo -u postgres psql -d mydb -c "SELECT PostGIS_Version();"

L’extension ajoute le type geography (sphère terrestre) et geometry (plan cartésien). Pour des points de livraison à Dakar, Abidjan ou Cotonou, utilisez geography qui calcule les distances en mètres en tenant compte de la courbure terrestre. Le SRID 4326 (WGS84, identique au GPS) est le standard.

Étape 5 : table de zones de livraison avec PostGIS

CREATE TABLE delivery_zones (
  id serial PRIMARY KEY,
  city text NOT NULL,
  area geography(Polygon, 4326),
  fee_fcfa integer NOT NULL
);

CREATE INDEX ON delivery_zones USING gist (area);

INSERT INTO delivery_zones (city, area, fee_fcfa) VALUES
('Dakar Plateau',
 ST_GeogFromText('POLYGON((-17.45 14.66, -17.42 14.66, -17.42 14.69, -17.45 14.69, -17.45 14.66))'),
 1500);

Pour savoir si une commande livrée à un point GPS tombe dans une zone : SELECT * FROM delivery_zones WHERE ST_Within(ST_MakePoint(-17.44, 14.67)::geography, area);. La requête s’exécute en moins de 5 ms grâce à l’index GiST, même avec 10 000 zones.

Étape 6 : TimescaleDB pour les séries temporelles

TimescaleDB 2.17 transforme PostgreSQL en base time-series performante. Installation sur Ubuntu 24.04 :

sudo apt install timescaledb-2-postgresql-17
sudo timescaledb-tune --quiet --yes
sudo systemctl restart postgresql
sudo -u postgres psql -d metrics -c "CREATE EXTENSION timescaledb;"

Convertissez une table classique en hypertable, ce qui partitionne automatiquement par tranches temporelles :

CREATE TABLE sensor_data (
  ts timestamptz NOT NULL,
  device_id text NOT NULL,
  temperature double precision,
  humidity double precision
);
SELECT create_hypertable('sensor_data', 'ts', chunk_time_interval => INTERVAL '7 days');

Sur 100 millions de lignes de mesures IoT collectées sur 2 ans, une requête d’agrégation par heure passe de 45 secondes (table classique) à 0,8 seconde (hypertable). Activez la compression native pour diviser le stockage par 10 : ALTER TABLE sensor_data SET (timescaledb.compress); SELECT add_compression_policy('sensor_data', INTERVAL '30 days');.

Étape 7 : pg_trgm pour recherche approximative

pg_trgm est livré avec PostgreSQL en contrib. Activez-le pour les recherches tolérantes aux fautes :

CREATE EXTENSION pg_trgm;
CREATE INDEX ON clients USING gin (nom gin_trgm_ops);
SELECT nom, similarity(nom, 'Mamadou Diallo') AS score
FROM clients
WHERE nom % 'Mamadou Diallo'
ORDER BY score DESC LIMIT 5;

L’opérateur % retourne les lignes dont la similarité dépasse 0,3 par défaut. Sur un fichier client de 200 000 noms, la requête répond en 12 ms. Indispensable pour un CRM qui doit gérer les variantes orthographiques (Mamadou / Mamadu, N’Diaye / Ndiaye).

Étape 8 : auditer les extensions installées

Listez les extensions actives avec SELECT extname, extversion FROM pg_extension ORDER BY extname;. Toute extension non documentée dans votre wiki d’équipe doit être désactivée via DROP EXTENSION nom CASCADE; après vérification qu’aucune table ne dépend de ses types. Documentez chaque extension dans un fichier db/EXTENSIONS.md versionné, avec la version installée, le cas d’usage métier, et le responsable. Cette discipline évite les surprises lors d’une montée de version PostgreSQL.

Étape 9 : sauvegarde et restauration avec extensions

pg_dump --extension=vector --extension=postgis n’existe pas : pg_dump exporte automatiquement les CREATE EXTENSION nécessaires. Toutefois, lors d’une restauration sur un nouveau serveur, vérifiez que les paquets OS correspondants sont installés avant de lancer pg_restore, sinon vous obtenez l’erreur extension "vector" is not available. Automatisez cette pré-installation dans votre script Ansible ou Terraform.

Sur un angle proche

Approfondissez avec notre tutoriel pgvector pour RAG qui montre comment connecter ces embeddings à un LLM, ou notre guide de hardening VPS pour sécuriser le serveur PostgreSQL.

Étape 10 : régler shared_preload_libraries

Certaines extensions exigent un chargement au démarrage du serveur via shared_preload_libraries. C’est le cas de TimescaleDB, pg_stat_statements et pg_cron. Éditez /etc/postgresql/17/main/postgresql.conf :

shared_preload_libraries = 'timescaledb,pg_stat_statements,pg_cron'
cron.database_name = 'mydb'

Redémarrez PostgreSQL puis vérifiez : SHOW shared_preload_libraries;. Une mauvaise configuration de cette directive est la cause numéro un des incidents de migration TimescaleDB que nous voyons sur les VPS de petites équipes. Toujours tester sur un serveur de staging avant la production.

Étape 11 : pg_stat_statements pour profiler

Cette extension trace toutes les requêtes SQL avec leur temps cumulé. Indispensable pour identifier la requête lente qui plombe l’application. Après activation :

SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 10;

Les 10 requêtes qui consomment le plus de CPU apparaissent en tête. Sur un site WooCommerce hébergé à Abidjan, nous avons identifié grâce à cet outil une jointure sur wp_postmeta sans index qui consommait 40 % du CPU PostgreSQL. Ajout d’un index : passage de 8 secondes à 80 ms par requête.

Étape 12 : pg_cron pour planifier les tâches SQL

Plutôt que d’ajouter une cron OS qui appelle psql, pg_cron 1.6 exécute les tâches dans le serveur PostgreSQL lui-même. Idéal pour les agrégations nocturnes ou la purge de données :

SELECT cron.schedule('purge_logs',
  '0 3 * * *',
  $$ DELETE FROM app_logs WHERE created_at < now() - INTERVAL '90 days' $$);

SELECT * FROM cron.job;

La tâche s'exécute chaque nuit à 3h du matin (heure UTC, ajoutez SET timezone='Africa/Dakar'; dans le job si nécessaire). Surveillez l'historique via SELECT * FROM cron.job_run_details ORDER BY start_time DESC LIMIT 20;.

Étape 13 : mises à jour et compatibilité

Quand vous montez de PostgreSQL 16 à PostgreSQL 17, chaque extension doit être mise à jour individuellement après la migration pg_upgrade. Procédure :

sudo apt update && sudo apt install postgresql-17-pgvector postgresql-17-postgis-3
sudo -u postgres psql -d mydb -c "ALTER EXTENSION vector UPDATE;"
sudo -u postgres psql -d mydb -c "ALTER EXTENSION postgis UPDATE;"
sudo -u postgres psql -d mydb -c "SELECT name, default_version, installed_version FROM pg_available_extensions WHERE installed_version IS NOT NULL;"

Si installed_version est inférieur à default_version, la mise à jour n'a pas été propagée. Forcez avec ALTER EXTENSION nom UPDATE TO 'version';. Documentez la version cible dans votre playbook Ansible ou votre Dockerfile pour garantir la reproductibilité entre staging et production.

Étape 14 : sécurité et permissions

Une extension peut introduire des fonctions exécutables par tout utilisateur connecté. Restreignez l'accès :

REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

Pour PostGIS, qui crée plus de 800 fonctions, ce verrouillage évite qu'un utilisateur compromis appelle ST_AsGeoJSON sur des données sensibles. Combiné avec un firewall PostgreSQL pg_hba.conf qui n'accepte que les connexions depuis l'application backend, vous obtenez une posture de sécurité conforme aux exigences ISO 27001.

Étape 15 : monitoring des extensions en production

Surveillez l'usage CPU et la taille des index spécifiques aux extensions. Pour pgvector, mesurez le temps moyen d'une recherche HNSW avec EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM faq ORDER BY embedding <=> '[...]'::vector LIMIT 5;. Au-delà de 50 ms, il faut soit augmenter ef_search, soit réindexer. Pour PostGIS, surveillez la taille des index GiST avec SELECT pg_size_pretty(pg_relation_size('idx_zones_area'));. Pour TimescaleDB, vérifiez la compression effective : SELECT chunk_name, before_compression_total_bytes, after_compression_total_bytes FROM chunk_compression_stats('sensor_data');. Un ratio inférieur à 5x signale des chunks mal compressibles, souvent à cause de colonnes JSONB volumineuses qu'il vaut mieux extraire dans une table séparée.

Étape 16 : pièges fréquents et bonnes pratiques

Trois erreurs reviennent dans les audits de bases PostgreSQL en production. Premièrement, créer un index HNSW pgvector sur une table vide avant l'insertion massive : la qualité de l'index s'effondre. Insérez d'abord toutes les données, puis créez l'index. Deuxièmement, oublier ANALYZE après un import massif : le planificateur PostgreSQL utilise des statistiques périmées et choisit des plans catastrophiques. Lancez VACUUM ANALYZE après chaque batch important. Troisièmement, mélanger les SRID dans PostGIS : un point en SRID 4326 (GPS) comparé à une zone en SRID 3857 (Web Mercator) renvoie des résultats faux sans alerte. Toujours vérifier SELECT ST_SRID(area) FROM delivery_zones LIMIT 1; avant les requêtes spatiales critiques.

Étape 17 : checklist finale avant mise en production

Avant de basculer une base avec extensions vers la production, validez chaque point. Versions des extensions documentées dans le dépôt. Sauvegarde testée avec restauration sur un serveur vierge. Index HNSW, GiST et BRIN créés après l'import massif. shared_preload_libraries aligné entre primaire et réplicas. Permissions REVOKE PUBLIC appliquées. Monitoring Prometheus ou Datadog branché sur pg_stat_statements. Plan de mise à jour rédigé, incluant la commande ALTER EXTENSION UPDATE pour chaque extension. Cette discipline, observée chez les meilleures équipes data ouest-africaines, fait la différence entre une base qui scale sereinement et une base qui s'écroule au premier pic de charge.