Database as a Service : liberté ou cage dorée ?

RDS, Cloud SQL, Azure SQL — le DBaaS promet la fin de la gestion. Mais derrière la promesse, il y a des limitations, des coûts cachés, et une dépendance.

La promesse

Le DBaaS (Database as a Service) promet : pas de gestion d'OS, pas de patches, pas de sauvegardes à gérer, haute disponibilité automatique, scalabilité facile. C'est séduisant. Pour une startup qui n'a pas de DBA, c'est parfait. Pour une entreprise qui veut réduire ses coûts d'infrastructure, c'est tentant.

La réalité n°1 : les limitations

RDS ne vous donne pas accès au serveur. Pas de sysadmin. Pas de xp_cmdshell. Pas de SQL Agent personnalisé. Pas de modifications de la configuration du serveur. Vous êtes dans une cage — confortable, mais cage.

Si vous avez besoin d'une fonctionnalité qui nécessite sysadmin, vous ne pouvez pas. Si vous avez un job SQL Agent complexe, il faut le réécrire. Si vous voulez installer une extension PostgreSQL non supportée, vous ne pouvez pas.

La réalité n°2 : les coûts cachés

Le DBaaS est plus cher que l'auto-hébergé. Une instance RDS m5.2xlarge coûte ~400€/mois. Une instance EC2 m5.2xlarge avec SQL Server installé coûte ~250€/mois. La différence : 150€/mois pour la gestion. Sur 10 instances, c'est 1 500€/mois, 18 000€/an.

Et ce n'est que le début. Les sauvegardes automatiques sont facturées séparément. Les snapshots manuels aussi. Le data transfer aussi. La haute disponibilité (Multi-AZ) double la facture. Au final, le DBaaS coûte 2-3x plus cher que l'auto-hébergé.

La réalité n°3 : la performance

Le DBaaS est souvent moins performant que l'auto-hébergé. Pourquoi ? Parce que vous partagez l'infrastructure. Le stockage est partagé (EBS pour RDS). Le réseau est partagé. Et vous ne pouvez pas tuner le serveur.

Sur des charges OLTP simples, la différence est négligeable. Sur des charges analytiques complexes, la différence peut être 2-3x. Si la performance est critique, le DBaaS peut être un mauvais choix.

La réalité n°4 : la dépendance

Une fois sur RDS, migrer vers une autre solution est coûteux. Les fonctionnalités RDS-specific (Aurora, par exemple) ne sont pas portables. Les configurations sont spécifiques. Les outils de monitoring sont spécifiques. Vous êtes locked-in.

Quand le DBaaS a du sens

1. Startup sans DBA. Si vous n'avez pas de DBA et que vous ne voulez pas en embaucher un, le DBaaS est parfait. La gestion est faite pour vous.

2. Bases de petite à moyenne taille. Jusqu'à 500 Go, le DBaaS est efficace. Au-delà, l'auto-hébergé devient plus économique.

3. Charges OLTP standard. Si vos requêtes sont simples et votre schéma est standard, le DBaaS fonctionne bien. Pour des charges complexes, l'auto-hébergé est meilleur.

4. Haute disponibilité sans expertise. Multi-AZ RDS vous donne une HA en un clic. Faire la même chose en auto-hébergé nécessite AlwaysOn, qui est complexe.

Quand l'auto-hébergé a du sens

1. Bases volumineuses. Au-delà de 1 To, le DBaaS devient très cher. L'auto-hébergé avec un serveur dédié est plus économique.

2. Charges complexes. Si vous avez besoin de tuning fin, d'extensions, de fonctionnalités sysadmin, l'auto-hébergé est nécessaire.

3. Conformité. Si vous avez des exigences de souveraineté ou de sécurité qui ne sont pas compatibles avec le DBaaS, l'auto-hébergé est la solution.

4. Coût. Si la facture DBaaS dépasse 5 000€/mois, l'auto-hébergé avec un DBA devient plus économique.

Conclusion

Le DBaaS n'est ni une liberté ni une cage. C'est un trade-off. Vous échangez la flexibilité contre la simplicité. Vous échangez le coût contre le temps. Le bon choix dépend de votre contexte : taille de la base, complexité des charges, expertise disponible, budget.

Ne choisissez pas le DBaaS par défaut. Ne choisissez pas l'auto-hébergé par principe. Choisissez en fonction de votre situation. Et revoyez votre choix régulièrement — ce qui était vrai à 100 Go ne l'est plus à 1 To.