Le terme « serverless » a été appliqué aux fonctions, aux API et, désormais, aux bases de données. Comme pour ses prédécesseurs, cela ne signifie pas qu'il n'y a pas de serveurs ; cela implique simplement que vous n'avez pas à vous en soucier. En effet, les bases de données serverless gèrent automatiquement le provisionnement, la mise à l'échelle et la planification de la capacité, ce qui permet aux développeurs de se concentrer sur le développement plutôt que sur la gestion de l'infrastructure. Pour les équipes habituées à dimensionner des instances RDS et à ajuster manuellement les répliques de lecture, ce changement peut sembler considérable. Cet article explique le fonctionnement des bases de données serverless, passe en revue les principales solutions disponibles et examine la manière dont Navicat s'intègre dans ce contexte.
Qu’est-ce qui caractérise une base de données « serverless » ?
La caractéristique principale d’une base de données sans serveur est la dissociation entre le stockage et la puissance de calcul. Dans un déploiement de base de données traditionnel, ces deux éléments sont étroitement liés : votre instance dispose d'une capacité fixe en termes de CPU, de mémoire et de disque, et vous faites évoluer le système en mettant à niveau l'instance. Dans une architecture serverless, le stockage est dissocié de la couche de calcul, ce qui permet à chacun d'évoluer indépendamment. La puissance de calcul peut augmenter pour absorber un pic de trafic, puis diminuer (voire être ramenée à zéro en période d'inactivité), tandis que les données restent intactes et disponibles.
Ce modèle a deux implications pratiques pour les développeurs. Premièrement, vous payez uniquement pour ce que vous consommez réellement, au lieu de réserver une capacité en prévision d'un pic d'activité. Deuxièmement, vous n'avez plus à vous soucier du dimensionnement de votre instance, car la base de données s'ajuste automatiquement.
Amazon Aurora Serverless
Aurora Serverless v2 est la configuration à la demande et à mise à l'échelle automatique d'Amazon pour Aurora, disponible dans les éditions compatibles MySQL et PostgreSQL. Elle s'adapte par incréments très fins — pouvant descendre jusqu'à 0,5 unité de capacité Aurora (ACU) — et peut évoluer sur une large plage sans perturber les connexions ou transactions actives. Contrairement à la première version, Aurora Serverless v1, qui présentait des problèmes notables de latence de démarrage à froid, la v2 évolue de manière beaucoup plus fluide et prend en charge l'ensemble des fonctionnalités d'Aurora, notamment les déploiements multi-AZ, les bases de données globales et les réplicas en lecture.
Aurora Serverless v2 constitue un excellent choix pour les applications présentant des charges de travail imprévisibles ou très variables, telles que les environnements de développement et de préproduction, les applications basées sur les événements ou tout système où la demande connaît des pics brusques et sporadiques. Son intégration profonde avec l'écosystème AWS en fait une solution toute indiquée pour les équipes qui exécutent déjà une infrastructure sur AWS.
Neon
Neon est une plateforme PostgreSQL « serverless » open source reposant sur une architecture dite « lakebase » : le stockage et le calcul y sont totalement dissociés, les données étant conservées dans un système de stockage d'objets cloud tandis que les nœuds de calcul peuvent réduire leur capacité à zéro lorsqu'ils sont inactifs. Lorsqu’une nouvelle requête arrive, la capacité de calcul est déployée en quelques secondes et se connecte à l’historique des données existant, sans aucun transfert de données.
L’une des fonctionnalités de Neon les plus appréciées des développeurs est la création de branches de base de données. À l'instar d'une branche Git, une branche Neon crée une copie isolée de votre base de données à un instant T, en utilisant la sémantique « copy-on-write » (copie à l'écriture). Aucune donnée n'étant dupliquée, la création de branches est instantanée et peu coûteuse. Il est ainsi très simple de créer une branche pour développer une fonctionnalité, d'y exécuter des migrations, puis de la supprimer une fois la tâche terminée, le tout sans jamais affecter l'environnement de production. Neon s'est imposé comme un choix privilégié pour les équipes développant sur PostgreSQL qui recherchent l'agilité du cloud-native sans pour autant renoncer à l'écosystème PostgreSQL.
PlanetScale
PlanetScale s'est initialement fait connaître en faisant entrer MySQL dans l'ère du « serverless » grâce à Vitess, la technologie de clustering de bases de données qui gère le trafic de YouTube. Sa contribution majeure au flux de travail des développeurs réside dans le « branching » (création de branches) de bases de données associé à des modifications de schéma non bloquantes : au lieu d'exécuter une commande `ALTER TABLE` directement en production -avec tous les risques que cela comporte-, vous créez une branche, effectuez la modification de schéma, ouvrez une demande de déploiement, puis fusionnez les branches le tout une fois prêt.
La plateforme a considérablement évolué ces dernières années. PlanetScale a supprimé son niveau gratuit « Hobby » en 2024 et s’est depuis réorienté vers une clientèle d’entreprise, avec des formules payantes à partir de 39 $ par mois. Elle a également étendu son offre au-delà de MySQL en lançant un service PostgreSQL géré avec partitionnement (« sharding ») et basé sur un stockage NVMe local. PlanetScale se positionne désormais résolument comme une plateforme haute performance et hautement évolutive, destinée aux équipes ayant des besoins importants en matière de débit, plutôt que comme une solution gratuite pour les passionnés.
Autres solutions notables
Le paysage des bases de données serverless ne se limite pas à ces trois solutions.
- Supabase superpose une plateforme backend complète à PostgreSQL, en y ajoutant l'authentification, le stockage et les abonnements en temps réel, en plus de l'hébergement de bases de données serverless.
- CockroachDB Serverless propose du SQL distribué avec un partitionnement (sharding) automatique entre les régions.
- Turso, basé sur libSQL (un fork de SQLite), cible les déploiements en périphérie repose sur un modèle d'isolation par base de données, garantissant une très faible latence.
Chacune de ces solutions se situe à un point différent du spectre entre simplicité et puissance.
Connexion aux bases de données « serverless » avec Navicat
L'un des défis pratiques liés aux bases de données sans serveur réside dans la nécessité de garantir la continuité de fonctionnement des outils déjà utilisés par les développeurs. Heureusement, la plupart de ces bases de données assurent délibérément une compatibilité totale au niveau du protocole réseau avec leurs moteurs sous-jacents, ce qui signifie que tout client capable de se connecter à MySQL ou PostgreSQL peut également s'y connecter y compris Navicat.
Navicat Premium prend en charge les connexions à Amazon Aurora directement via son type de connexion Amazon AWS intégré, grâce auquel vous pouvez configurer une connexion Aurora et bénéficier du même environnement complet (éditeur de requêtes, visualiseur de données, gestion des schémas, transfert de données) que celui que vous utiliseriez avec une instance MySQL ou PostgreSQL traditionnelle. Pour Neon et PlanetScale, les connexions s’établissent respectivement à l’aide des types de connexion PostgreSQL et MySQL standard de Navicat. Les deux plateformes fournissent une chaîne de connexion standard depuis leurs tableaux de bord ; il vous suffit de saisir l’hôte, le port, le nom de la base de données et les identifiants dans la boîte de dialogue de connexion de Navicat, d’activer SSL si nécessaire, puis de vous connecter.
Cela signifie que le workflow pour lequel les bases de données sans serveur sont conçues – itérations rapides, création de branches, modifications de schéma sécurisées – peut être associé aux outils de Navicat pour l’analyse des requêtes, l’explication visuelle, la synchronisation des données et la comparaison de schémas. Vous bénéficiez ainsi de la simplicité opérationnelle d’une infrastructure sans serveur sans renoncer à la richesse d’un environnement professionnel de gestion de bases de données.
Quelques points de vigilance
Les bases de données « serverless » ne sont pas systématiquement supérieures aux bases de donées provisionnées. Le phénomène de « démarrage à froid » (cold start) reste un facteur important pour les applications sensibles à la latence, même si la situation s'est nettement améliorée avec les plateformes récentes. La gestion des connexions peut également se comporter différemment : comme la puissance de calcul peut être réduite à zéro puis rétablie, la mise en pool des connexions est plus importante que jamais. Bien que la plupart des plateformes l'intègrent nativement, il est utile de comprendre comment la plateforme choisie gère les connexions avant de passer en production. Enfin, la tarification à la consommation peut être plus difficile à prévoir qu'un coût mensuel fixe par instance, en particulier pour les applications soumises à des charges de travail élevées et constantes, pour lesquelles une base de données provisionnée pourrait s'avérer plus économique.
Conclusion
Les bases de données « serverless » ont considérablement évolué et constituent désormais un choix viable pour un large éventail de charges de travail en production, et non plus uniquement pour les environnements de développement. Aurora Serverless v2, Neon et PlanetScale proposent chacun une approche distincte de ce modèle ; le choix idéal dépendra de vos préférences en matière de moteur, de vos besoins de mise à l'échelle et de vos priorités opérationnelles. Ces solutions ont en commun de réduire considérablement la charge opérationnelle. De plus, comme elles sont toutes compatibles avec les normes MySQL ou PostgreSQL, leur connexion et leur gestion via Navicat ne nécessitent aucune configuration particulière ni aucun compromis en termes de fonctionnalités.
