Pourquoi héberger sa base de données sur son propre VPS
Auto-héberger votre base sur VPS vous donne un contrôle total sur la version du moteur, les paramètres de tuning, le chiffrement et la latence réseau vers votre application. Plutôt que de subir les limites de connexions et le surcoût d'une base managée, vous co-localisez la base et l'app sur le même réseau privé : le trajet réseau sort de l'équation, et ce qui reste — la requête, l'index, le volume — se mesure sur votre propre charge. PostgreSQL excelle sur les schémas complexes, les contraintes strictes, le JSONB indexable, les requêtes analytiques et les extensions (PostGIS, pg_trgm, recherche full-text). MySQL (ou MariaDB) reste imbattable de simplicité, très bien supporte par les CMS et frameworks PHP, avec des lectures rapides. Le bon choix dépend de la nature de vos données, pas d'une préférence de principe.
Ce que l'auto-hébergement apporte à votre base
- Aucun saut réseau public : la base sur le même réseau privé que l'application
- Maîtrise totale du tuning :
shared_buffers,innodb_buffer_pool_size, connexions max - Choix libre de la version et du calendrier de mise à jour
- Sauvegardes logiques et physiques planifiées selon vos besoins réels
- Réplication et lecture distribuée configurées à votre main
- Chiffrement au repos et accès restreint au seul réseau interne du VPS
Prérequis pour une base de données sur VPS
Une base de développement ou un petit site vit confortablement sur 1 vCPU et 1 Go de RAM. En production, la règle d'or est de dimensionner la RAM pour que l'index de travail tienne en cache : visez 2 à 4 Go pour PostgreSQL (shared_buffers autour de 25% de la RAM) et un innodb_buffer_pool_size couvrant votre jeu de données actif pour MySQL. Un disque SSD/NVMe est non négociable pour les écritures. Prévoyez Docker et Compose, un volume persistant dédié aux données, et surtout : n'exposez jamais le port de la base sur Internet. L'accès se fait via le réseau Docker interne ou un tunnel SSH.
Déployer PostgreSQL (ou MySQL) sur VPS avec Docker
Créer un volume persistant
Définissez un volume nommé pgdata (ou mysqldata) dans Compose. Ne stockez jamais les données dans la couche éphémère du conteneur : un docker compose down ne doit pas détruire votre base.
Configurer le service et les secrets
Déclarez l'image postgres:16 ou mysql:8, injectez les identifiants via un fichier .env (jamais en clair dans le compose), et bindez le port uniquement en local : 127.0.0.1:5432:5432. La base ne doit pas être joignable depuis l'extérieur.
Démarrer et vérifier
Lancez docker compose up -d puis testez la connexion en interne avec docker compose exec db psql -U app -d maBase (ou mysql -u). Vérifiez l'encodage (UTF8/utf8mb4) dès la création pour éviter les surprises.
Appliquer le tuning
Montez un fichier de config personnalisé pour ajuster shared_buffers, work_mem et max_connections (PostgreSQL) ou innodb_buffer_pool_size et max_connections (MySQL) en fonction de la RAM réelle du VPS. Redémarrez le service pour appliquer.
Mettre en place les sauvegardes
Planifiez un dump régulier via cron : pg_dump ou mysqldump compresse, copie hors du VPS. Testez la restauration : une sauvegarde jamais restaurée n'est pas une sauvegarde.
Sécuriser l'accès applicatif
Faites communiquer l'app et la base via le réseau Docker interne uniquement. Pour un accès admin distant, passez par un tunnel SSH plutôt que d'ouvrir le port. Créez un utilisateur applicatif aux droits limites, distinct du super-utilisateur.
| Critère | PostgreSQL | MySQL / MariaDB |
|---|---|---|
| Modèle de données | Riche : types personnalisés, tableaux, JSONB | Solide, plus classique |
| Support JSON | JSONB indexable et performant | JSON présent, indexation plus limitée |
| Conformité SQL / contraintes | Très stricte (CHECK, types, transactions DDL) | Plus permissive |
| Recherche full-text / geo | Native + PostGIS, pg_trgm | Basique, extensions tierces |
| Lectures simples haute fréquence | Très bonnes | Excellentes, très optimisées |
| Réplication | Streaming, logique | Maître-esclave, simple à mettre en place |
| Écosystème CMS/PHP | Bon | Référence (WordPress, etc.) |
| Empreinte mémoire | Modérée | Légère à modérée |
Quel que soit le moteur, ne laissez jamais une application web ouvrir une connexion directe par requête : sur PostgreSQL placez PgBouncer en pooler, et sur MySQL ajustez max_connections avec un pool côté application. Un VPS qui s'effondre sous la charge a presque toujours un problème de connexions non poolées plutôt qu'un manque de puissance brute.
