Neon dévoile une nouvelle approche du développement de bases de données : Neon PostgresSQL. Neon permet de réduire les coûts de démarrage, d'arrêt, de création et de clonage des bases de données de plusieurs heures à quelques secondes.Postgres reste l'une des bases de données de développement les plus populaires jamais créées. Alors que MySQL a perdu de son éclat après son rachat par Oracle, Postgres continue de gagner la confiance des développeurs. En 2023, elle est arrivée en tête du sondage StackOverflow Developers Survey et, la même année, a été élue SGBD de l'année par DBEngines. Le mème internet actuel est "Just Use Postgres" pour tout.
Malgré sa popularité, Postgres souffre des deux problèmes qui affectent presque toutes les bases de données relationnelles. Il est difficile d'augmenter ou de diminuer la taille de la base de données sans interruption. Pire encore, il faut beaucoup de temps pour rétablir les opérations de production lorsque des bogues logiciels affectent les données.
En effet, avec Postgres, il est difficile de créer un environnement de développement très fidèle, car il faut copier l'état complet de la base de données. De plus, le maintien de plusieurs copies des données et du schéma pour chaque développeur est une véritable plaie. La base de données devient le point névralgique du développement pour la plupart des équipes et constitue invariablement le goulot d'étranglement qui limite la vélocité des développeurs.
Les besoins des développeurs
Lorsque l'équipe d'ingénieurs de Neon a abordé ces questions, elle savait qu'elle devait résoudre plusieurs problèmes liés au cycle de vie actuel du développement des bases de données :
- Ils voulaient que la création d'un cluster Postgres soit rapide (moins d'une seconde).
- Ils voulaient que les clusters Postgres soient capables d'évoluer automatiquement vers le haut ou vers le bas en fonction de la charge. Vous n'avez pas à vous soucier d'un provisionnement excessif ou insuffisant.
- Ils voulaient pouvoir créer des branches avec des données complètes copiées instantanément afin que les développeurs puissent travailler indépendamment tout en étant capables de collaborer efficacement.
- Ils voulaient pouvoir restaurer un point dans le temps en quelques secondes au lieu d'heures ou de jours.
Presque toutes les applications ont besoin d'une base de données, et alors que les outils et les flux de travail des développeurs ont évolué avec des plateformes comme GitHub et Vercel, les bases de données n'ont pas évolué pour correspondre à l'expérience des développeurs de ces systèmes. L'évolution de l'expérience des développeurs autour de la base de données nécessite de repenser fondamentalement l'architecture de la base de données. Mais il ne s'agit pas d'un moteur "regardez notre nouvelle base de données cool". les développeurs aiment et veulent utiliser l'authentique logiciel open-source Postgres.
C'est pourquoi, chez Neon, ils ont cherché à modifier l'expérience de développement sur Postgres sans perdre tout ce qui fait la qualité de Postgres.
Nous avons emprunté une idée à Amazon Aurora, la séparation du stockage et de l'informatique, et nous ne parlons pas de la simple utilisation d'un disque connecté au réseau comme EBS. Une véritable séparation du stockage et du calcul a ouvert la possibilité de faire évoluer les deux parties du service de manière indépendante. Contrairement à AWS Aurora, nous avons décidé de mettre en open source toutes les modifications apportées à Postgres et de les envoyer en amont, ainsi que de mettre en open source notre stockage natif dans le nuage.
Nous avons pris des décisions architecturales qui garantissent à nos utilisateurs une expérience complète de Postgres, y compris les extensions, les éléments internes, la ligne de commande et les outils de gestion. Tout ce qui fonctionne sur site devrait fonctionner dans notre service en nuage.
Nous avons pris des décisions architecturales qui garantissent à nos utilisateurs une expérience complète de Postgres, y compris les extensions, les éléments internes, la ligne de commande et les outils de gestion. Tout ce qui fonctionne sur site devrait fonctionner dans notre service en nuage.
Qu'est-ce que cela signifie pour l'utilisateur ?
Cela signifie qu'on peut créer des branches à tout moment et démarrer une instance de calcul pointant vers cette version de base de données. Ainsi, chaque développeur peut travailler sur une branche différente sans empiéter sur le travail de ses collègues.
L'informatique peut désormais évoluer indépendamment du stockage, de sorte que la taille et le nombre de CPU peuvent correspondre précisément à la charge. Même les charges de bases de données importantes connaissent des pics et des creux. L'équipe de Neon voulait éviter aux développeurs d'avoir à dimensionner leur système en fonction de la plus grande charge attendue.
Une branche de base de données est copiée à l'écriture, ce qui signifie qu'elle pointe uniquement vers un ensemble de pages déjà créées et stockées. La création d'une branche prend donc moins d'une seconde. Parce qu'elles sont copiées en écriture, les branches ne subissent aucune surcharge d'espace jusqu'à ce que des données leur soient écrites.
Supposons qu'un développeur mette fin à une table ou à une base de données à l'aide d'un "fat finger" ? Pas de problème, il suffit de déplacer la branche à la seconde précédant cet événement. Le démarrage d'une nouvelle base de données ou la reprise d'une production défaillante se fait en quelques secondes, car l'architecture Neon ne nécessite pas l'envoi de centaines de gigaoctets de données pour créer de nouvelles instances de bases de données et de serveurs.
Les utilisateurs ne veulent pas de bases de données, ils veulent des données. Neon est conçu pour réduire les coûts de démarrage, d'arrêt, de création et de clonage des bases de données de plusieurs heures à quelques secondes. La base de données relationnelle est le principal frein à la vélocité du développement moderne. Imaginez que les données soient faciles à obtenir, quel serait l'impact sur la productivité de vos développeurs ?
Avec Neon, le branchement des bases de données est intégré directement dans le flux de travail du développeur, sans interruption. Lorsque les modifications des données et/ou du schéma de la base de données prennent des heures à se propager au sein de l'équipe de développement, tout le monde en pâtit.
Neon est le prochain grand pivot de Postgres, et tous ces changements ont été proposés en amont à la communauté Postgres. Ils sont disponibles dans notre repo public dès aujourd'hui. Notre mission est de fournir tout ce dont les développeurs Postgres ont besoin et moins. Moins d'attente pour le démarrage des clusters, moins d'attente pour la restauration des bases de données, moins d'attente pour le déploiement des changements entre collègues, moins d'attente pour la programmation des mises à jour par l'équipe DBA.
Comment Neon en est arrivé là ?
Au cours de son avant-première, l'équipe de Neon s'est concentré sur la construction d'une base technique solide pour Neon. Voici quelques-unes de ses étapes :
- En décembre 2022, ils ont supprimé l'accès à Neon sur invitation uniquement. Aujourd'hui, des milliers de nouvelles bases de données Neon sont créées chaque semaine. Neon comprend un niveau gratuit généreux qui est là pour rester : l'architecture de Neon permet de la supporter efficacement.
- Ils ont rendu le branchement de bases de données accessible à tous. Aujourd'hui, des dizaines de milliers de branches sont créées chaque semaine par les utilisateurs de Neon. Les branches Neon incluent les données et les schémas, ce qui permet aux développeurs de créer des copies isolées de leurs données en une seconde.
- Neon a également inclus la prise en charge de l'API dès le départ. L'API de Neon est aujourd'hui devenue un outil robuste qui permet aux partenaires de Neon de gérer facilement des parcs de centaines de milliers de bases de données. Ils automatisent toutes les opérations de base de données via l'API, ce qui supprime le besoin de DevOps dédiés à la gestion des parcs Postgres.
- Ils ont également lancé un pilote sans serveur. Aujourd'hui, le pilote sans serveur Neon compte plus de 100 000 téléchargements hebdomadaires. Les développeurs l'utilisent pour accélérer leurs déploiements JavaScript et Typescript.
- En ce qui concerne l'accélération des déploiements, ils ont lancé l'intégration Vercel, qui crée une branche de base de données pour chaque prévisualisation. Aujourd'hui, des milliers de branches de base de données Neon ont été créées via l'intégration Vercel.
- Quelques mois après le début de la Preview, ils ont publié la première version de l'autoscaling, une fonctionnalité fondamentale qui élargit l'expérience sans serveur de Neon. Aujourd'hui, des milliers d'événements de mise à l'échelle automatique se produisent chaque semaine, évitant aux développeurs le travail de redimensionnement manuel.
- Ils ont également mis le CLI de Neon à la disposition de tous les utilisateurs, afin que les développeurs puissent simplifier leurs intégrations et leurs automatismes en gérant Neon directement depuis leur terminal. Aujourd'hui, ce CLI compte des centaines d'utilisateurs actifs hebdomadaires.
- Au cours des mois d'avant-première, ils ont mis l'accent sur l'amélioration du comportement de mise à zéro et de démarrage à froid. Aujourd'hui, des dizaines de milliers de bases de données Neon sont mises à zéro chaque jour, ce qui permet aux développeurs d'économiser de l'argent. Ils continuent à travailler sur les mesures de démarrage à froid : on est maintenant à un P50 de 500 ms pour démarrer une base de données, et ils travaillent à le réduire encore plus.
Neon Postgres est généralement disponible. La mise à l'échelle automatique sans serveur et le branchement instantané sont conçus pour les développeurs modernes qui doivent itérer rapidement.
Source : Annonce de Neon
Et vous ?
Quel est votre avis sur le sujet ? Pensez-vous que Neon PostgresSQL est crédible ou pertinent ?Voir aussi :
Le projet PostgreSQL étudie un changement majeur qui pourrait sacrifier des fonctionnalités importantes. Pour les bénéfices attendus, cela vaut-il la peine ? Postgres 16 est désormais disponible dans Azure Cosmos DB for PostgreSQL, alimenté par Citus La Grande Migration de MongoDB vers PostgreSQL : comment Infisical a réussi le passage. Quelles sont les raisons qui l'ont motivée à quitter MongoDB et pourquoi s'est-elle orientée vers PostgreSQL ? 
Envoyé par SQLpro
