Le serverless database est la promesse la plus séduisante du cloud : pas de gestion, scale infini, payez ce que vous consommez. Sauf que la réalité est très différente. Démontons les 7 mensonges un par un.
Mensonge 1 : "Pas de gestion"
Faux. Vous ne gérez plus l'OS ni les patches, c'est vrai. Mais vous gérez toujours les index, les statistiques, les requêtes lentes, la fragmentation. Le serverless ne supprime pas l'optimisation — il la rend même plus difficile parce que vous avez moins de visibilité.
Mensonge 2 : "Scale infini"
Le serverless scale — mais avec des cold starts. Aurora Serverless v2 peut mettre plusieurs secondes à s'allouer après une période d'inactivité. Pour une API qui répond en 200ms, un cold start de 5 secondes est catastrophique. Et vous ne contrôlez pas quand ça arrive.
Mensonge 3 : "Payez ce que vous consommez"
Aurora Serverless facture par ACU (Aurora Capacity Unit) avec un minimum de 0.5 ACU. Sur une base qui tourne 24/7, même au minimum, c'est ~350€/mois. Une instance RDS t3.medium qui fait la même chose coûte 60€/mois. Le serverless est 5x plus cher au minimum.
Mensonge 4 : "Pas de latence"
Le connection pooling du serverless ajoute de la latence. Chaque connexion passe par un proxy qui route vers l'instance. Sur des charges à forte concurrence, cette latence s'accumule et devient perceptible.
Mensonge 5 : "Toutes les fonctionnalités"
Aurora Serverless v1 ne supportait pas les Global Tables, les clones, ni les réplicas lus. La v2 a corrigé beaucoup de ces limitations, mais il reste des fonctionnalités non disponibles. Vérifiez la compatibilité avant de migrer.
Mensonge 6 : "Moins cher à grande échelle"
À grande échelle, le serverless devient plus cher que le provisionné. Au-delà de 70% d'utilisation moyenne, une instance provisionnée avec reserved instances coûte moins cher. Le serverless est intéressant seulement pour les charges très variables avec des pics courts.
Mensonge 7 : "Migration facile"
La migration vers serverless nécessite souvent des changements d'application : gestion des connexions différent, timeouts à ajuster, fonctionnalités non disponibles. Ce n'est pas un flip de switch.
Quand le serverless a du sens
Le serverless database est pertinent pour : les charges très intermittentes (dev/test, batchs ponctuels), les startups qui ne connaissent pas leur volume, les environnements multi-tenant avec isolation. Pour tout le reste, le provisionné reste plus économique et plus prévisible.
Et vous ?
Vous envisagez le serverless database ? Aprilium analyse votre charge et vous dit honnêtement si le serverless vous fera économiser de l'argent — ou en dépenser plus.
Analyser ma charge