Les meilleures alternatives à la plateforme d'applications DigitalOcean pour les charges de travail importantes en 2026

DigitalOcean App Platform est une plateforme PaaS gérée qui permet de déployer à partir de Git ou d’une image de conteneur, avec HTTPS automatique, une facturation auprès d’un seul fournisseur et un parcours vraiment simple, du dépôt au service opérationnel. Pour les petites équipes et les produits en phase de démarrage, c’est cette simplicité qui fait tout l’intérêt.

Mais les limites apparaissent dès que la charge de travail augmente. La fonctionnalité d’auto-scaling d’App Platform s’est améliorée en 2026 : l’auto-scaling basé sur les requêtes, qui réagit au nombre de requêtes par seconde et à la latence P95, a été mis à la disposition de tous en mai 2026 et fonctionne désormais aussi bien sur les forfaits CPU partagés que sur les forfaits CPU dédiés, et non plus uniquement sur ces derniers. L’auto-scaling basé sur le CPU nécessite toujours un forfait CPU dédié. La couche de base de données n’a pas bénéficié de la même mise à niveau. Les bases de données gérées de DigitalOcean adaptent automatiquement la capacité de stockage, en surveillant l’utilisation du disque et en ajoutant de la capacité en arrière-plan sans aucun temps d’arrêt. 

La couche de calcul, c'est-à-dire le processeur et la mémoire vive sur lesquels tourne un cluster de bases de données, ne s'adapte pas du tout automatiquement : pour l'augmenter, il faut passer à un forfait plus puissant, une modification qu'une personne ou un pipeline doit déclencher. Face à une charge de travail intense et soutenue, la couche applicative peut réagir aux signaux en temps réel. La couche de calcul de la base de données ne le peut pas ; seul son disque en est capable.

Ce guide présente les plateformes vers lesquelles les équipes se tournent lorsque c’est précisément cet écart entre la base de données et la puissance de calcul, et non la couche applicative, qui motive leur décision.

Points clés à retenir

• Ce guide compare DigitalOcean App Platform à des plateformes offrant une véritable solution pour la mise à l’échelle de la puissance de calcul des bases de données sous forte charge, et pas seulement pour la croissance du stockage, à l’horizon 2026.
• Upsun est la solution la mieux adaptée aux équipes qui souhaitent que leurs applications, leurs workers et leurs répliques de lecture PostgreSQL ou MariaDB gérées s’adaptent automatiquement et indépendamment en temps réel, en fonction de leur propre charge CPU et mémoire, sans ajouter de fournisseur de base de données distinct à la stack.
• Les plateformes de bases de données spécialisées résolvent spécifiquement les problèmes de la couche de base de données : Neon pour le calcul Postgres sans serveur, PlanetScale pour le partitionnement MySQL basé sur Vitess, CockroachDB Serverless pour le SQL distribué, et AWS Aurora Serverless v2 pour les équipes déjà engagées sur AWS. Chacune d’entre elles laisse toutefois la question de l’hébergement des applications à résoudre séparément.
• Render est inclus car c’est la solution full-stack qui se rapproche le plus de l’expérience proposée par DigitalOcean, avec un compromis clairement énoncé : sa base de données s’adapte en fonction du forfait que tu choisis, et non automatiquement.

Ce qu’il faut rechercher dans une alternative à la plateforme d’applications DigitalOcean axée sur l’auto-scaling

• L’auto-scaling des ressources de calcul de la base de données par opposition à l’auto-scaling du stockage uniquement. Il s’agit de savoir si le CPU et la mémoire d’une base de données s’adaptent automatiquement à la charge, ou si seul le stockage sur disque le fait, laissant l’augmentation des ressources de calcul à un changement manuel de forfait.
• Ce qui s'adapte réellement automatiquement. Certaines plateformes adaptent automatiquement l'instance principale en lecture-écriture. D'autres adaptent automatiquement les répliques de lecture, tandis que l'instance principale continue de s'adapter verticalement via une configuration manuelle. Cette distinction est importante pour les charges de travail à forte intensité d'écriture.
• Plateforme « full-stack » ou service dédié uniquement à la base de données. La plateforme héberge-t-elle aussi l’application, ou s’agit-il d’une base de données à laquelle tu te connectes depuis une application hébergée ailleurs ?
• Prise en charge du multicloud et du BYOC (Bring Your Own Cloud). La plateforme fonctionne-t-elle sur AWS, GCP, Azure ou d’autres fournisseurs, ou lie-t-elle une équipe à un seul cloud ?
• Modèle de tarification. Basé sur les ressources, sur la consommation ou sur un forfait, et si ce modèle récompense ou pénalise le dimensionnement optimal.
• Conformité. Certifications telles que ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1, HIPAA et RGPD, et si elles couvrent aussi les environnements hors production.

Pourquoi la couche de base de données de DigitalOcean atteint ses limites sous une charge importante

Les notes de mise à jour de DigitalOcean décrivent l’auto-scaling basé sur les requêtes, disponible depuis mai 2026, qui réagit en temps réel au nombre de requêtes par seconde et à la latence de réponse P95, tant sur les instances d’applications à CPU partagé que sur celles à CPU dédié. L’auto-scaling basé sur le CPU reste limité aux forfaits à CPU dédié. Ça, c’est le niveau « application », et c’est une vraie amélioration par rapport à l’ancien modèle « tout ou rien » de l’App Platform, qui ne proposait que des instances dédiées.

Les bases de données gérées n’ont pas bénéficié d’une mise à niveau équivalente. L’autoscaling du stockage est disponible pour tous et automatique : la documentation de DigitalOcean explique qu’elle surveille en continu l’utilisation du disque et augmente la capacité de stockage en arrière-plan lorsqu’un seuil configuré est dépassé, sans interruption de service ni intervention manuelle. Pour le CPU et la RAM, c’est une autre histoire. Redimensionner la puissance de calcul, ça veut dire choisir une nouvelle taille de forfait via la console ou l’API, une action qu’une équipe décide de prendre ; la documentation de DigitalOcean sur le redimensionnement décrit ça comme une opération asynchrone qui n’entraîne pas de temps d’arrêt pour la plupart des moteurs, mais c’est un changement que quelqu’un ou quelque chose doit déclencher. Sous une charge de travail intense et soutenue, le disque s’adapte tout seul. La puissance de calcul qui traite les requêtes, elle, ne s’adapte pas, jusqu’à ce qu’une personne ou un pipeline la redimensionne.

Upsun, dont on parle plus bas, est l’alternative conçue pour combler cette lacune spécifique : les applications, les tâches en arrière-plan et les répliques de lecture PostgreSQL ou MariaDB s’adaptent automatiquement et indépendamment en temps réel, en fonction de leur propre charge CPU et mémoire, sans ajouter de fournisseur de base de données distinct à la stack.

Les meilleures alternatives à la plateforme d’applications DigitalOcean pour les charges de travail intensives en 2026

Upsun

Une plateforme d’applications multicloud où les applications, les tâches en arrière-plan et les répliques de lecture gérées de PostgreSQL ou MariaDB partagent le même mécanisme de mise à l’échelle automatique.

Upsun exécute des applications sur AWS, GCP, Azure, OVHcloud et IBM Cloud à partir d’un seul processus piloté par Git. L’auto-scaling applique le même modèle à trois niveaux, chacun surveillé et mis à l’échelle indépendamment en temps réel : les applications (en production depuis le lancement initial de la fonctionnalité), les workers en arrière-plan (depuis mars 2026) et, depuis juillet 2026, les répliques de lecture PostgreSQL et MariaDB.

 Chaque niveau surveille sa propre utilisation de CPU et de mémoire par rapport aux seuils configurés par une équipe, puis ajoute ou retire de la capacité en conséquence. Ainsi, un pic de trafic de lecture peut déclencher l’autoscaling des répliques sans toucher à la capacité de l’application ou des workers, et l’inverse est également vrai. L’instance principale de la base de données en lecture-écriture continue d’évoluer verticalement via une configuration manuelle, comme ça a toujours été le cas ; ce qui a changé, c’est que la couche des répliques de lecture n’a plus besoin d’un opérateur dédié ni d’une demande de redimensionnement manuelle pour faire face à une charge importante en lecture.

Fonctionnalités clés :

• Mise à l’échelle automatique indépendante et en temps réel pour les applications, les workers et les répliques de lecture PostgreSQL ou MariaDB, chacune avec ses propres seuils de CPU et de mémoire, configurés par environnement.
• Déploiement multicloud sur AWS, GCP, Azure, OVHcloud et IBM Cloud.
• Catalogue de services gérés comprenant PostgreSQL, MariaDB, Redis, Elasticsearch, OpenSearch, RabbitMQ et Kafka.
• Tarification basée sur les ressources, calculée par application, worker et service.
• Conformité aux normes ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1, HIPAA et RGPD

Idéal pour : les équipes qui gèrent un stack applicatif complet soumis à une charge importante ou irrégulière et qui souhaitent que le trafic de base de données, principalement en lecture, s'adapte automatiquement à la charge de leurs applications et de leurs nœuds de travail, sans avoir à faire appel à un fournisseur de base de données distinct ou à un opérateur Kubernetes.

Avantages :

• Les applications, les workers et les répliques de lecture de la base de données s’adaptent via la même console, CLI ou API, sur une seule facture.
• L'auto-scaling des répliques de lecture ajoute ou supprime de la capacité sans redémarrage ni basculement.
• L’option multicloud évite de lier la décision de mise à l’échelle de la base de données à un seul hyperscaler.

Inconvénients :

• La mise à l'échelle automatique concerne les répliques de lecture, mais pas l'instance principale d'écriture, qui reste à dimensionner verticalement via une configuration manuelle.
• La mise à l'échelle automatique de la base de données est disponible sur le niveau de service « Upsun Cloud » ; « Upsun Fixed » ne prend en charge que la mise à l'échelle manuelle.

Neon

Une plateforme Postgres sans serveur qui sépare la puissance de calcul du stockage, ce qui permet à la puissance de calcul de s'adapter automatiquement de manière indépendante, par branche.

Neon exécute Postgres standard, la puissance de calcul étant mesurée en unités de calcul (CU), chacune correspondant approximativement à un vCPU et 4 Go de RAM. Une équipe définit une plage minimale et maximale de CU par branche, et Neon ajuste la puissance de calcul dans cette plage en fonction des variations de charge, en réduisant jusqu’à zéro après une période d’inactivité sur les forfaits éligibles. Comme le stockage et la puissance de calcul sont dissociés, la création de branches sur une grosse base de données pour un aperçu ou un test de migration ne nécessite pas de copier les données sous-jacentes.

Principales fonctionnalités :

• Mise à l'échelle automatique de la puissance de calcul dans une plage de CU configurable, par branche.
• Réduction à zéro après une période d’inactivité, avec un bref démarrage à froid lors de la connexion suivante.
• Création de branches en « copy-on-write » pour des copies de base de données isolées, identiques à celles de production.
• Ressources de calcul pour les répliques en lecture, indépendantes de la plage de mise à l’échelle automatique du serveur principal.
• Protocole réseau Postgres standard, sans couche de requêtes propriétaire.

Idéal pour : les équipes dont le goulot d'étranglement est spécifiquement lié à la puissance de calcul de Postgres sous une charge importante et variable, et qui hébergent leur application ailleurs.

Avantages :

• L'auto-scaling de la puissance de calcul est le cœur du produit Neon, pas un simple module complémentaire.
• La fonctionnalité « Scale-to-zero » élimine les coûts liés aux branches inactives et aux environnements de test.
• Postgres standard signifie que les pilotes, ORM et extensions existants sont généralement compatibles.

Inconvénients :

• Neon est un service de base de données, pas un hébergeur d’applications ; une équipe a donc toujours besoin d’un endroit où faire tourner son application, et la mise à l’échelle de cette application est un problème à part qu’il faut résoudre.
• La plage de mise à l'échelle automatique du forfait « Launch » plafonne à 8 CU ; le forfait « Scale » fait passer ce plafond à 16 CU, avec des tailles fixes (sans mise à l'échelle automatique) disponibles au-delà pour les charges de travail stables et à forte intensité.

PlanetScale

Une plateforme compatible MySQL basée sur Vitess, le système de partitionnement initialement conçu pour faire évoluer la base de données de YouTube.

PlanetScale ajoute à MySQL la création de branches de base de données, des migrations de schéma sans blocage et une mise à l’échelle automatique des disques, Vitess gérant le partitionnement horizontal au niveau de la couche de stockage. La mise à l’échelle automatique des disques fonctionne par défaut sur des clusters de stockage en réseau (NAS), en augmentant ou en réduisant les volumes dans les limites autorisées par le stockage en bloc dans le cloud. PlanetScale propose également un nouveau produit Postgres, bien qu’il s’agisse d’un ajout plus récent que l’offre MySQL basée sur Vitess pour laquelle la société est surtout connue.

Principales fonctionnalités :

• Partitionnement horizontal automatique basé sur Vitess pour les charges de travail compatibles avec MySQL.
• Mise à l'échelle automatique des disques, avec augmentation des volumes sur place comme mode par défaut.
• Migrations de schémas sans blocage grâce à un processus de type « branch-and-deploy-request ».
• Répliques en lecture et mise en commun automatisée des connexions.

Idéal pour : les équipes qui utilisent MySQL avec un volume d'écriture important, qui s'attendent à dépasser à terme la capacité d'un seul serveur principal et qui recherchent une solution de partitionnement ne nécessitant pas de refonte de l'architecture ultérieure.

Avantages :

• Le partitionnement Vitess a fait ses preuves depuis longtemps en production à très grande échelle.
• La mise à l'échelle automatique des disques et les migrations sans blocage réduisent les opérations manuelles sur la base de données.
• La création de branches offre un processus de type Git pour les modifications de schéma.

Inconvénients :

• Le point fort principal, c'est MySQL ; les équipes qui utilisent Postgres devraient comparer le nouveau produit Postgres de PlanetScale à des options spécifiques à Postgres plus éprouvées avant de se lancer.
• Comme Neon, il s’agit d’un service de base de données plutôt que d’un hébergeur d’applications ; l’auto-scaling au niveau des applications ne fait donc pas partie de l’offre.

CockroachDB Serverless

Une base de données SQL distribuée, compatible au niveau du code avec Postgres, que Cockroach Labs décrit comme adaptant automatiquement la capacité de stockage et de traitement des transactions.

CockroachDB Serverless facture le stockage et les « Request Units » (une mesure abstraite de l’activité des requêtes), et s’adapte à la hausse comme à la baisse sans que l’équipe ait à choisir à l’avance la taille de l’instance. Les données sont automatiquement répliquées, et le déploiement multirégional est intégré au produit plutôt que d’être une étape de configuration distincte.

Principales fonctionnalités :

• Mise à l'échelle automatique du stockage et de la capacité transactionnelle, selon la description du produit fournie par Cockroach Labs.
• Tarification à la consommation avec un niveau gratuit (5 Gio de stockage, 50 millions d’unités de requête par mois).
• Déploiement multirégional et réplication des données intégrés.
• Pilotes, ORM et syntaxe SQL compatibles avec Postgres.

Idéal pour : les équipes qui ont besoin d'une base de données distribuée multi-régions et qui souhaitent que la mise à l'échelle du stockage et de la puissance de calcul soit gérée automatiquement en cas de forte charge, sans partitionnement manuel.

Avantages :

• S'adapte automatiquement sans qu'il soit nécessaire de choisir à l'avance la taille de l'instance.
• La prise en charge multirégionale et la réplication sont intégrées au produit, pas ajoutées après coup.
• Le niveau gratuit est suffisant pour une utilisation en production à un stade précoce.

Inconvénients :

• C'est un moteur SQL distribué qui utilise le protocole réseau de Postgres plutôt que Postgres lui-même en amont ; il faut donc vérifier la compatibilité des extensions spécifiques dont dépend une application par rapport à la documentation de CockroachDB.
• Comme les autres solutions « uniquement base de données » présentées ici, il n’héberge pas la couche applicative ; il résout donc la question de la mise à l’échelle de la base de données de manière isolée, plutôt qu’en parallèle de celle de l’application et des workers.

AWS Aurora Serverless v2

La base de données gérée par Amazon, compatible avec Postgres et MySQL, dotée d’une configuration sans serveur qui adapte automatiquement la puissance de calcul dans une plage définie.

Une équipe définit une plage minimale et maximale d’unités de capacité Aurora (ACU), et Aurora s’adapte en fonction des variations de charge. Depuis une mise à jour de novembre 2024, le minimum peut être fixé à 0 ACU sur les versions de moteur prises en charge, ce qui permet une mise en pause automatique en cas d’inactivité et une reprise automatique à la prochaine connexion. RDS Standard pour Postgres, en dehors de la configuration Serverless v2, ne permet pas l’auto-scaling de la puissance de calcul : pour redimensionner, il faut changer de classe d’instance de base de données, ce qui provoque une brève interruption pendant l’opération de modification.

Fonctionnalités clés :

• Mise à l'échelle automatique de la puissance de calcul dans une plage d'ACU configurable.
• Mise en pause automatique à 0 ACU sur les versions prises en charge d’Aurora PostgreSQL et d’Aurora MySQL.
• Intégration poussée avec le reste de l’écosystème AWS : IAM, VPC, CloudWatch, Secrets Manager.
• Mise à l'échelle automatique du stockage, indépendamment de la configuration de la puissance de calcul.

Idéal pour : les équipes déjà engagées sur AWS qui souhaitent bénéficier d’une mise à l’échelle automatique de la puissance de calcul des bases de données en tant que fonctionnalité gérée au sein de RDS, plutôt que d’adopter un nouveau fournisseur de bases de données.

Avantages :

• La mise à l'échelle automatique par plage d'ACU est désormais une fonctionnalité AWS aboutie et largement utilisée.
• La mise en pause automatique permet de réduire les coûts pour les clusters utilisés de manière intermittente.
• Pas besoin de nouer de nouvelle relation avec un fournisseur pour les équipes qui utilisent déjà l’infrastructure AWS.

Inconvénients :

• Aurora Serverless v2 est une solution exclusivement AWS ; elle ne répond donc pas aux besoins de multi-cloud ou de BYOC (Bring Your Own Cloud) auxquels certaines équipes cherchent à répondre en parallèle.
• Le RDS standard pour Postgres (contrairement à Aurora Serverless v2 en particulier) nécessite toujours un changement manuel de classe d’instance, qui entraîne une brève interruption, pour redimensionner la base.
• Aurora Serverless v2 fait évoluer la base de données ; le calcul applicatif sur AWS est un service distinct (App Runner, ECS ou similaire) avec sa propre configuration d’évolutivité.

Render

La solution full-stack la plus proche de l’expérience développeur proposée par la DigitalOcean App Platform, avec des bases de données basées sur des forfaits et dimensionnées manuellement.

Render se déploie depuis Git avec des services web, des workers en arrière-plan, des tâches cron, ainsi que Postgres et Redis gérés en tant que types de services de premier plan. La mise à l’échelle de la base de données se fait via le choix d’un forfait : tu choisis une taille d’instance pour le CPU, la mémoire et le disque, puis tu ajoutes des répliques de lecture lorsque la charge de lecture doit être allégée. D’après la documentation de Render, les répliques correspondent toujours au type d’instance de la primaire et sont facturées en conséquence ; la mise en veille haute disponibilité nécessite un type d’instance « Pro » ou « Accelerated », et son activation entraîne le redémarrage de la base de données.

Principales fonctionnalités :

• Déploiement basé sur Git avec des services web, des workers, des tâches cron et des bases de données gérées comme types de premier plan.
• Répliques de lecture pour les charges de travail à forte intensité de lecture, ajoutées via le tableau de bord.
• Mode de secours haute disponibilité sur les types d’instances éligibles.
• Conformité SOC 2 Type 2, ISO 27001, RGPD et prise en charge HIPAA sur demande.

Idéal pour : les équipes qui recherchent avant tout une expérience plus aboutie, auprès d’un fournisseur unique, proche de celle proposée par DigitalOcean, et qui préfèrent planifier elles-mêmes la capacité de leur base de données plutôt que de recourir à l’auto-scaling.

Avantages :

• Un modèle « full-stack » familier, proche de ce à quoi s’attend déjà un utilisateur de la plateforme d’applications DigitalOcean.
• La tarification par forfait est facile à prévoir.
• Postgres et Redis gérés sans avoir à passer par un autre fournisseur.

Inconvénients :

• La mise à l'échelle de la base de données se fait manuellement : il faut choisir un forfait et, si besoin, ajouter des répliques soi-même.
• L'activation de la haute disponibilité redémarre la base de données.
• La mise à l'échelle au niveau de l'application et celle au niveau de la base de données ne suivent pas le même modèle d'auto-scaling ; une équipe planifie la capacité de la base de données indépendamment de la manière dont ses services web et ses workers s'adaptent.

Comparaison des alternatives

Choisir la bonne solution

La décision principale, c’est de savoir si la base de données doit évoluer dans le cadre d’une plateforme « full-stack », ou en tant que service autonome avec l’appli hébergée ailleurs. Les deux options sont viables ; la différence, c’est le nombre de fournisseurs qui se retrouvent dans la pile et qui décide de l’hébergement de l’appli.

Upsun, c’est l’option qui regroupe tout — applications, workers et répliques de lecture de la base de données — dans un seul modèle à mise à l’échelle automatique, chaque couche réagissant en temps réel à sa propre charge CPU et mémoire, le tout sur une seule facture. C’est ce qui compte le plus pour les équipes qui ne veulent pas faire appel à un fournisseur de base de données distinct juste pour combler le fossé de mise à l’échelle de calcul que la base de données gérée de DigitalOcean laisse ouvert. Neon, PlanetScale et CockroachDB Serverless se concentrent chacun sur un moteur de base de données et un modèle de mise à l’échelle spécifiques : l’élasticité de calcul de Postgres, le partitionnement de MySQL et le SQL distribué, respectivement, et chacun part du principe que l’hébergement de l’application sera géré ailleurs. Aurora Serverless v2 est le bon choix pour les équipes déjà standardisées sur AWS qui préfèrent étendre RDS plutôt que d’ajouter un nouveau fournisseur. Render mérite d’être mentionné clairement : c’est celui qui se rapproche le plus de l’expérience de DigitalOcean, et le compromis à prendre en compte, c’est que sa base de données s’adapte au forfait choisi par l’équipe, et non de manière autonome.

Foire aux questions 

La base de données gérée de DigitalOcean App Platform s'adapte-t-elle automatiquement en cas de forte charge ?

En partie. Le stockage s’adapte automatiquement : les bases de données gérées de DigitalOcean surveillent l’utilisation du disque et ajoutent de la capacité en arrière-plan, sans interruption de service, lorsqu’un seuil configuré est dépassé. La puissance de calcul, c’est-à-dire le processeur et la mémoire vive sur lesquels tourne un cluster de bases de données, ne s’adapte pas automatiquement. Pour l’augmenter, il faut passer à un forfait plus élevé via la console ou l’API, une modification que l’équipe doit déclencher elle-même.

La plateforme DigitalOcean App Platform adapte-t-elle automatiquement la capacité des applications ?

Oui, mais ça dépend de l’indicateur utilisé. L’auto-scaling basé sur les requêtes, qui réagit au nombre de requêtes par seconde et à la latence P95, est disponible pour tous depuis mai 2026 et fonctionne aussi bien sur les forfaits CPU partagés que dédiés. L’auto-scaling basé sur le CPU est pour l’instant limité aux forfaits CPU dédiés.

Quelle alternative à DigitalOcean App Platform gère automatiquement la mise à l’échelle des ressources de calcul des bases de données ?

Neon adapte automatiquement la puissance de calcul de Postgres dans une plage configurable par branche, y compris une adaptation à zéro pour les branches inactives. Upsun adapte automatiquement les répliques de lecture PostgreSQL et MariaDB dans le cadre de la même fonctionnalité qui adapte ses applications et ses workers, tandis que l’instance d’écriture principale s’adapte toujours verticalement via une configuration manuelle. AWS Aurora Serverless v2 adapte automatiquement la puissance de calcul dans une plage d’ACU pour les équipes déjà sur AWS.

Est-ce qu’Upsun adapte automatiquement la capacité de l’instance principale de la base de données ou seulement celle des répliques de lecture ?

Seules les répliques de lecture, depuis la mise à jour de juillet 2026 de la fonctionnalité d’auto-scaling d’Upsun. L’instance principale en lecture-écriture de PostgreSQL ou MariaDB continue d’évoluer verticalement via une configuration manuelle, comme avant. Ce sont les charges de travail à forte intensité de lecture soumises à une charge importante qui bénéficient directement du nouveau comportement d’auto-scaling.

Est-ce que PlanetScale ou Neon convient le mieux à une équipe qui quitte la plateforme d’applications DigitalOcean ?

Ça dépend du moteur de base de données déjà utilisé. PlanetScale repose sur Vitess et est particulièrement adapté aux charges de travail compatibles MySQL soumises à un volume d’écriture important et qui devraient à terme nécessiter un partitionnement horizontal. Neon est une plateforme Postgres sans serveur et convient mieux aux équipes qui utilisent déjà Postgres et qui souhaitent que la puissance de calcul s’adapte automatiquement sans adopter un modèle de partitionnement basé sur MySQL.

Une équipe peut-elle migrer de la DigitalOcean App Platform vers ces alternatives sans réécriture ?

En général, ça se fait par des changements de configuration plutôt que par une réécriture complète, même si la charge de travail varie selon la plateforme. Passer à Render, c’est presque une migration à l’identique, puisque les deux sont des plateformes full-stack basées sur Git avec Postgres géré intégré. Passer à Upsun implique d’ajouter un fichier de configuration YAML décrivant l’application et ses services. Passer à une plateforme exclusivement dédiée à la base de données, comme Neon, PlanetScale, CockroachDB Serverless ou Aurora Serverless v2, signifie conserver l’application hébergée là où elle tourne déjà (ou la déplacer séparément) et la rediriger vers la nouvelle base de données, ce qui se résume généralement à modifier la chaîne de connexion, plus les éventuelles différences de schéma ou d’extension introduites par le nouveau moteur.