PostgreSQL vient de franchir un cap historique. Avec 55.6% d'adoption chez les développeurs (contre 48.7% en 2024), la base de données open-source enregistre la plus forte progression annuelle de son histoire : 7 points de pourcentage en un an. Ce n'est pas un accident. Les versions 17 et 18 ont apporté des améliorations de performance majeures, et l'intégration native des capacités vectorielles pour l'IA fait de PostgreSQL la base de données universelle que beaucoup cherchaient.
L'adoption en chiffres
Le Stack Overflow Developer Survey 2025 (50 000+ développeurs, 177 pays) place PostgreSQL en tête des bases de données :
| Base de données | Adoption | Evolution |
|----------------|----------|-----------|
| PostgreSQL | 55.6% | +7 pts |
| MySQL | 40.5% | Stable |
| SQLite | 32% | Stable |
| MongoDB | 26% | -2 pts |
| Redis | 22% | Stable |
Chez les développeurs professionnels, l'écart se creuse encore : 58.2% utilisent PostgreSQL, soit 18.6 points d'avance sur MySQL. PostgreSQL est aussi la base de données la plus admirée (65%) et la plus désirée (46%) pour la troisième année consécutive.
39 062 entreprises utilisent PostgreSQL en production en 2026. L'écosystème cloud suit : AWS RDS/Aurora, Google Cloud SQL et Azure Database proposent tous PostgreSQL comme service managé de premier plan.
PostgreSQL 17 : le vacuum qui change tout
La version 17, sortie en octobre 2024, a résolu un problème historique de PostgreSQL : la lourdeur du processus VACUUM.
Le problème
VACUUM est le processus qui nettoie les lignes supprimées ou modifiées dans les tables PostgreSQL (MVCC oblige). Sur les grosses tables, ce processus consommait jusqu'à 1 Go de mémoire et pouvait dégrader les performances des requêtes en cours.
La solution : TidStore et Adaptive Radix Trees
PostgreSQL 17 remplace la structure de données du VACUUM par un TidStore basé sur des arbres radix adaptatifs :
- 20x moins de mémoire consommée pour les opérations VACUUM
- Suppression de la limite de 1 Go qui plafonnait le traitement (179+ millions de tuples désormais traitables)
- 20% plus rapide sur les benchmarks autovacuum
- 50% de réduction mémoire pour le stockage des dead tuples
L'overhead devient proportionnel au volume d'écritures, pas à la taille de la table. Une table de 500 Go avec peu de modifications consomme autant de ressources VACUUM qu'une table de 5 Go avec le même volume d'écritures.
Autres améliorations PostgreSQL 17
- Scan d'index bidirectionnel : les index B-tree peuvent être parcourus dans les deux sens, améliorant certains plans de requêtes
- COPY parallèle amélioré : import de données plus rapide
- Optimisations de requêtes : meilleur traitement des sous-requêtes et des jointures
PostgreSQL 18 : I/O asynchrone et contraintes temporelles
La version 18, sortie en septembre 2025, apporte deux avancées majeures.
I/O asynchrone : jusqu'à 3x plus rapide
PostgreSQL 18 introduit les I/O asynchrones pour les scans séquentiels, les bitmap heap scans et les opérations VACUUM. Au lieu de traiter les requêtes I/O une par une (synchrone), le moteur soumet plusieurs requêtes en parallèle au système de stockage.
Le gain mesuré : jusqu'à 3x de performance en lecture, configurable via le paramètre io_method. Sur les workloads analytiques (scans de grandes tables, agrégations), l'impact est immédiat.
Contraintes temporelles natives
C'est une fonctionnalité que les développeurs attendaient depuis des années. PostgreSQL 18 supporte nativement la clause WITHOUT OVERLAPS sur les PRIMARY KEY, UNIQUE et FOREIGN KEY :
CREATE TABLE reservations (
room_id integer,
booking tstzrange,
guest_name text,
PRIMARY KEY (room_id, booking WITHOUT OVERLAPS)
);
PostgreSQL garantit qu'aucune réservation ne se chevauche pour la même salle. Plus besoin de triggers custom ou de logique applicative. Les cas d'usage sont nombreux : réservations, planning d'employés, gestion de créneaux, versioning temporel.
Autres nouveautés PostgreSQL 18
- Colonnes virtuelles générées : valeurs calculées au moment de la requête
- UUIDv7 : UUID ordonnés par timestamp, meilleur pour l'indexation que UUIDv4
- RETURNING avec OLD et NEW : accès aux valeurs avant et après modification
- Authentification OAuth 2.0 : première nouvelle méthode d'authentification depuis des années
- Builds parallèles d'index GIN : accélération de l'indexation full-text
- Accélération hardware : instructions ARM NEON et SVE pour les opérations CPU-intensives
PostgreSQL comme base vectorielle : pgvector et VectorChord
L'adoption massive de l'IA en production a créé un besoin de bases de données vectorielles. Plutôt que d'ajouter un système dédié (Pinecone, Weaviate, Qdrant), de plus en plus d'équipes utilisent PostgreSQL directement.
pgvector : l'extension qui simplifie tout
pgvector permet de stocker, indexer et rechercher des embeddings IA directement dans PostgreSQL :
-- Créer une table avec une colonne vectorielle
CREATE TABLE documents (
id serial PRIMARY KEY,
content text,
embedding vector(1536) -- OpenAI ada-002 dimensions
);
-- Index pour la recherche de similarité
CREATE INDEX ON documents
USING ivfflat (embedding vector_cosine_ops);
L'avantage est considérable : pas de base de données supplémentaire à maintenir, pas de synchronisation de données, et toute la puissance de PostgreSQL (transactions ACID, jointures, backups) reste disponible. Les trois grands cloud providers (AWS, GCP, Azure) proposent pgvector en extension managée.
VectorChord : la génération suivante
VectorChord, successeur de pgvecto.rs, pousse les performances plus loin :
- Index sur 1 milliard de vecteurs constructible sur une machine 128 Go de RAM
- Quantification 4-bit (RaBitQ4) et 8-bit (RaBitQ8) avec moins de 1% de perte de recall
- Compatible avec la syntaxe pgvector
- Pas de tuning complexe de paramètres
Pour les projets RAG (Retrieval-Augmented Generation) en production, PostgreSQL + VectorChord élimine la nécessité d'une base vectorielle dédiée dans la plupart des cas.
PostgreSQL vs MySQL vs MongoDB en 2026
Quand choisir PostgreSQL
- Requêtes complexes : jointures, sous-requêtes, CTEs, window functions
- Types de données avancés : arrays, JSON, ranges, vecteurs, géospatial (PostGIS)
- Conformité ACID stricte avec support transactionnel complet du DDL
- Extensibilité : pgvector, PostGIS, TimescaleDB, Citus
- Row Level Security : contrôle d'accès au niveau ligne
Quand MySQL reste pertinent
- Applications web simples avec schéma stable
- Workloads très intensifs en écriture : overhead par connexion plus faible (threads vs processes)
- DDL online : options INSTANT, INPLACE, COPY plus matures
- Base installée : si l'écosystème existant tourne sur MySQL, la migration a un coût
Quand MongoDB a du sens
- Schéma imprévisible : données semi-structurées ou non structurées
- Prototypage rapide : pas de schéma à définir au démarrage
- Sharding natif : scaling horizontal intégré
- Documents JSON natifs : si la structure de données est naturellement documentaire
Ce qu'il faut retenir
PostgreSQL n'est plus seulement une alternative à MySQL. C'est devenu la base de données par défaut pour les nouveaux projets, tous domaines confondus. Les raisons sont concrètes :
- Performance : VACUUM 20x plus léger (PG 17), I/O 3x plus rapides (PG 18)
- IA native : pgvector et VectorChord éliminent le besoin d'une base vectorielle dédiée
- Fonctionnalités : contraintes temporelles, colonnes virtuelles, OAuth 2.0
- Écosystème : extensions de qualité production pour chaque cas d'usage
Si vous démarrez un nouveau projet en 2026 et que vous n'avez pas de raison spécifique de choisir autre chose, PostgreSQL est le choix par défaut. La communauté, l'écosystème et les performances sont là pour le justifier.