Quand on utilise PostgreSQL avec Spring Boot, le pool de connexions HikariCP devient un levier de performance incontournable.
Bien configuré, il réduit la latence, évite les blocages et absorbe les pics de charge. Mal dimensionné… il devient vite un goulot d’étranglement silencieux.
voici mes 5 recommandations pour tirer le meilleur parti d’Hikari :
✅ 1. Ajustez le maximumPoolSize intelligemment
Ce n’est pas un chiffre arbitraire. Il doit être calibré en fonction de la capacité de votre base de données à accepter des connexions concurrentes. Trop élevé = surcharge. Trop bas = goulot d’étranglement.
✅ 2. Spécifiez minimumIdle selon le comportement attendu
Si vos requêtes sont fréquentes, préservez quelques connexions prêtes à l’emploi.
Si l’appli est peu sollicitée en heures creuses, réduisez minimumIdle pour économiser les ressources.
✅ 3. Utilisez connectionTimeout pour éviter les blocages
Ne laissez pas vos utilisateurs attendre indéfiniment. 30 secondes ? Trop long. En général, entre 2 et 5 secondes suffit pour détecter un problème.
✅ 4. Activez les logs Hikari en cas de doute
spring.datasource.hikari.pool-name, spring.datasource.hikari.register-mbeans=true, et le logging DEBUG : très utile pour comprendre les comportements du pool en prod.
✅ 5. Attention au piège du autoCommit
Selon votre stratégie de transaction, ajustez https://lnkd.in/eRz9KKhF-commit pour éviter les effets de bord silencieux.
Une configuration conseillée pour PostgreSQL dans application.yml
---
Vous cherchez un Développeur Backend Java expérimenté ? Je suis disponible ! Discutons : https://lnkd.in/ecRArCmt
Ou envoyez-moi un message en DM
Sur le papier et lorsque tu n'a qu'une seule instance de ton app, ça marche nickel.
Dans une ère de plus en plus cloudifiée, où on a besoin de Scalabilité et d'Elasticité, ce modèle ne tient plus la route.
Si tu as plusieurs replicas de ton application, chaque replica va gérer son propre pool de connections, et c'est dommage, puisque ça serait retour à la case de départ.
Aujourd'hui il existe pas mal de middlewares pour partager et mutualisés les pool de connections. Le plus connu c'est PGBouncer.
Sur AWS on a du AWS RDS Proxy.
Sur GCP, Cloud SQL à une feature de gestion centralisée de pool de connections
La connaissance de ces paramètres m’a été utile dans le contexte d’une application Spring Boot multi-instance déployée sur Cloud Run avec une base de données Cloud SQL (PostgreSQL).