PostgreSQL
Définition
Base de données relationnelle open-source robuste, standard du marché pour les applications web modernes. Supporte SQL complet, JSON natif et de nombreuses extensions (pgvector, PostGIS).
Comment ça marche
PostgreSQL est une base de données relationnelle open-source qui stocke les données en tables structurées et les interroge en SQL. Le moteur gère le contrôle de concurrence multi-version (MVCC), ce qui permet aux lectures de ne jamais bloquer les écritures et inversement. Chaque transaction obtient une vue cohérente de la base à son démarrage, sans verrouiller les autres. La base propose des fonctionnalités avancées : index B-tree, GIN et GiST, types JSON natifs, recherche plein texte, transactions ACID. Elle tourne sur Linux, macOS et Windows, et accepte des extensions pour étendre ses capacités sans toucher au cœur du moteur.
À quoi ça sert
PostgreSQL couvre 95% des besoins backend d'une application moderne : SaaS B2B avec multi-tenant, e-commerce avec catalogue et commandes, outils internes avec workflows complexes, applications mobiles avec API. Les requêtes complexes (jointures multi-tables, agrégations, fenêtrage analytique) tournent vite grâce à l'optimiseur. La gestion JSON permet de mélanger schéma rigide et champs flexibles dans la même table, utile pour les configurations utilisateur ou les métadonnées variables. On l'utilise aussi pour des cas moins évidents : queue applicative légère, cache applicatif, recherche full-text, stockage de vecteurs IA via pgvector.
Les extensions qui changent tout
Le vrai atout de PostgreSQL réside dans son écosystème d'extensions. pgvector ajoute le support des embeddings pour le RAG, sans avoir à monter une base vectorielle dédiée. PostGIS gère les données géographiques avec une qualité qui rivalise avec les solutions spécialisées. pg_cron exécute des tâches programmées directement dans la base. TimescaleDB transforme PostgreSQL en base de séries temporelles pour les métriques IoT. pg_trgm accélère les recherches floues sur le texte. Ces extensions s'activent en une commande SQL et évitent d'empiler des services tiers. Sur un projet, ça simplifie l'architecture et réduit drastiquement les coûts d'infrastructure.
Où l'héberger
L'offre est dense en 2026. Supabase combine PostgreSQL managé avec auth, stockage et edge functions, idéal pour démarrer vite un SaaS. Neon propose un PostgreSQL serverless qui scale à zéro entre les requêtes, parfait pour les projets à trafic irrégulier. Render et Railway offrent du managé simple à prix raisonnable. AWS RDS et Google Cloud SQL ciblent les charges enterprise avec SLA stricts. Pour les charges constantes et un budget maîtrisé, un VPS chez Hetzner ou Scaleway avec PostgreSQL auto-hébergé reste imbattable. Le format de dump étant standard, on migre d'un hébergeur à l'autre en quelques heures.
Les pièges à éviter
Sans index, une table d'un million de lignes met plusieurs secondes à répondre. On profile les requêtes lentes avec EXPLAIN ANALYZE et on ajoute les bons index, pas tous les index. Les connexions sont coûteuses : sur un environnement serverless, on passe par un pooler (PgBouncer, Supavisor) pour ne pas saturer la base. Les migrations de schéma sur une grosse table peuvent bloquer la production, on les fait en plusieurs étapes (ajouter colonne nullable, backfill, ajouter contrainte). Les transactions longues empêchent le VACUUM de nettoyer, ce qui fait gonfler la base. Ces points se gèrent une fois compris, mais ils piquent quand on les découvre en production.
Les alternatives
MySQL reste répandu mais souffre face à PostgreSQL sur les requêtes analytiques, le JSON et les contraintes complexes. SQLite suffit pour des apps locales ou des prototypes, jamais pour un SaaS multi-utilisateur. MongoDB séduit par son côté schemaless mais on regrette vite l'absence de jointures et de transactions multi-document fiables. Les bases NewSQL distribuées (CockroachDB, YugabyteDB) compatibles PostgreSQL ciblent les besoins de scalabilité horizontale extrême. Pour la grande majorité des projets jusqu'à plusieurs millions d'utilisateurs, PostgreSQL classique sur une machine bien dimensionnée tient sans difficulté. On change rarement de base, autant choisir celle qui couvre le plus de cas.
Les bonnes pratiques
On utilise UUID pour les identifiants exposés publiquement, jamais des auto-incréments numériques qui révèlent les volumes. Les contraintes (NOT NULL, CHECK, FOREIGN KEY) vivent dans la base, pas seulement dans le code applicatif. La Row Level Security gère l'isolation multi-tenant au niveau de la base, pas dans chaque requête. Les migrations passent par un outil versionné (Drizzle, Prisma Migrate, Flyway) qui garde l'historique en Git. On sauvegarde la base quotidiennement avec un test de restauration mensuel, car une sauvegarde non testée n'existe pas. Le monitoring suit la latence des requêtes, le taux de cache hit et la taille des index.