On vous propose de « tout mettre sur S3 » pour réduire la facture. Sauf que votre PostgreSQL tourne déjà sur un volume bloc NVMe — et qu'un DBA vous rappelle que les bases ne vivent pas dans des buckets.
Le stockage bloc (volume attaché à un VPS, disque cloud, SAN) expose un device /dev/sdb formaté en ext4 ou XFS. Le moteur de base y fait des lectures/écritures aléatoires, des fsync, des verrous. Le stockage objet expose des clés ; chaque PUT remplace l'objet entier. Confondre les deux modèles sur des données qui changent toutes les secondes est l'une des erreurs d'architecture les plus coûteuses.
Bloc versus objet : sémantique d'accès
| Besoin | Disque bloc | Stockage objet |
|---|---|---|
| MySQL / PostgreSQL / MongoDB local | Oui | Non |
| Redis persistence AOF/RDB | Oui | Non |
| Upload photo immuable | Possible mais lourd | Idéal |
| Logs append-only archivés | Bloc puis rotation → objet | Idéal (lifecycle) |
| Modifications partielles fréquentes | Oui (offset write) | Non (rewrite full object) |
| Snapshots crash-consistent | Oui (avec précautions) | Versioning par objet |
Mettre une base sur S3 « parce que c'est scalable » ignore que la scalabilité des bases se joue sur réplication, pas sur des PUT HTTP.
Données qui changent souvent : rester en bloc
Moteurs relationnels. Data directory, WAL, binlog : latence p99 et IOPS provisionnés déterminent la tenue en charge. Les offres cloud « database optimized » ou volumes NVMe existent pour ça.
Caches persistants. Redis AOF, sessions fichier : petites écritures fréquentes — mauvais fit objet.
Applications legacy POSIX. ERP qui écrit des centaines de petits fichiers temporaires dans /tmp/app : bloc ou local SSD.
Conteneurs avec état local. Volume Docker nommé pour Elasticsearch ou Prometheus TSDB — bloc attaché, snapshots réguliers.
Bonnes pratiques bloc : snapshots avant upgrade majeur ; monitoring IOPS et espace libre avec alerte à 80 % ; séparer data et OS sur deux volumes pour restauration ciblée.
Données qui changent peu ou une fois : objet gagne
Médias utilisateurs. Écriture unique, lectures multiples via CDN.
Backups et dumps. pg_dump compressé vers bucket avec rétention 30 jours — classique et économique.
Logs froids. Rotation locale 48 h sur bloc, agrégation vers bucket classe froide.
Artifacts CI. Binaires versionnés, immuables par hash.
Scaleway, OVHcloud et les hyperscalers facturent bloc et objet séparément : comparez egress quand la base restaure depuis S3 vers un nouveau volume.
Le piège hybride mal exécuté
Pattern sain : base sur NVMe, fichiers sur objet, métadonnées en SQL.
Pattern toxique : base sur bloc et fichiers applicatifs critiques uniquement sur bloc sans backup objet — perte du volume = perte totale. Pattern inverse toxique : tenter SQLite sur NFS monté depuis une passerelle objet — latence et corruption.
Le sommet : la facture S3 n'est pas la facture architecture
Décider et avancer sans angle mort
Listez chaque datastore avec son rythme d'écriture : opérations par seconde, taille moyenne, mutable ou immuable. Placez bases et caches sur bloc dimensionné après mesure IOPS en charge réelle. Exportez sauvegardes et médias vers objet avec règles de cycle de vie.
Testez restauration volume bloc et restauration objet isolé — pas seulement la création du backup. Parcourez offres bloc et objet dans notre comparateur. Pour fichiers applicatifs versus NAS, voir Stockage objet ou NAS.
Questions fréquentes
Peut-on héberger MySQL sur du stockage objet ?
Non en production standard. MySQL exige filesystem bloc à faible latence. Objet pour dumps et archives.
Quand S3 remplace-t-il un volume bloc ?
Fichiers écrits une fois puis lus, via SDK/CDN. Réécritures fréquentes favorisent le bloc.
Les snapshots bloc suffisent-ils comme backup ?
Non seuls. Combinez snapshots, export objet off-site et tests de restauration.
Comment choisir la taille IOPS ?
Profilez en pic : IOPS sustained, latence p99. Évitez sur- et sous-dimensionnement aveugle.
Avant de migrer une base « vers le cloud », une question : combien d'écritures aléatoires par seconde ? Si vous ne savez pas, le disque bloc n'est pas encore dimensionné — et S3 n'est pas la réponse.