Les meilleures alternatives à Railway pour faire évoluer les bases de données de production en 2026

Railway est l’un des moyens les plus simples de déployer une application. Il suffit de connecter un dépôt Git, de pousser le code, et quelques minutes plus tard, un service opérationnel côtoie une base de données gérée. Pour les projets parallèles et les produits en phase de démarrage, cette rapidité est difficile à battre.

C’est au niveau de la couche de base de données que le fossé apparaît. Les conteneurs d’applications de Railway s’adaptent verticalement tout seuls à mesure que la demande augmente, et l’évolutivité horizontale est disponible pour les applications si une équipe connecte son propre système d’évolutivité automatique à l’API publique de Railway. 

Les bases de données gérées qui côtoient ces applications — Postgres, MySQL, Redis et MongoDB — ne bénéficient pas du même traitement. Le redimensionnement des volumes de disque se fait manuellement via une action du tableau de bord. Les augmentations de puissance de calcul verticale au-delà des limites du forfait standard passent par un accord de dépenses engagées, dans le cadre duquel l’équipe de Railway réserve manuellement la charge de travail sur du matériel dédié. Quand le trafic explose, la couche applicative arrive souvent à suivre le rythme. La base de données, en revanche, n’y arrive généralement pas, du moins pas sans que quelqu’un s’en aperçoive et intervienne.

Ce guide présente les plateformes vers lesquelles les équipes se tournent lorsque c’est la base de données, et non l’application, qui les pousse à chercher une alternative à Railway en 2026.

Points clés à retenir

• Ce guide compare Railway à des plateformes offrant une véritable solution pour la mise à l’échelle de la couche base de données, et pas seulement celle des applications, à l’horizon 2026.
• Upsun est la solution la plus adaptée aux équipes qui souhaitent disposer d’une seule fonctionnalité d’auto-scaling pour les applications, les workers et les répliques de lecture PostgreSQL ou MariaDB gérées, 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 de Railway, avec un compromis clairement énoncé : sa base de données s’adapte selon le forfait que tu choisis, et non automatiquement.

Ce qu’il faut rechercher dans une alternative à Railway axée sur la mise à l’échelle des bases de données

• Mise à l’échelle automatique de la base de données ou redimensionnement manuel. La question est de savoir si la puissance de calcul, le stockage ou le nombre de répliques s’ajustent automatiquement en fonction de la charge, ou si la mise à l’échelle implique de choisir une instance plus grande et de redéployer.
• 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 s’adapte toujours 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 également 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 Railway atteint ses limites

La documentation de Railway sur la mise à l’échelle décrit des conteneurs d’application qui s’adaptent automatiquement à la verticale jusqu’aux limites de CPU et de mémoire du forfait, ainsi qu’un nombre de répliques pour la mise à l’échelle horizontale qui « reste par défaut tel que tu l’as défini », ajustable via l’API publique si une équipe développe son propre système de mise à l’échelle automatique. C’est la couche application.

La couche base de données fonctionne selon un modèle différent. Le stockage réside sur un volume dont la taille augmente via une action manuelle de redimensionnement en temps réel dans le tableau de bord de Railway, et non de manière automatique. L’augmentation des limites de calcul verticales pour une base de données au-delà du niveau de ressources standard est gérée dans le cadre d’une formule « Business Class » : un engagement de dépenses mensuelles en vertu duquel l’équipe de Railway réserve manuellement la charge de travail sur son matériel, selon au moins un échange documenté avec le support de Railway. 

Rien de tout ça n’est inhabituel pour une plateforme PaaS axée sur les développeurs. Ça veut dire que quand un pic de trafic touche la base de données plutôt que l’application, la réponse, c’est un échange avec le support ou un clic dans le tableau de bord, pas un ajustement automatique.

Les meilleures alternatives à Railway pour faire évoluer les bases de données en 2026

Upsun

Une plateforme d’applications multicloud où les applications, les workers en arrière-plan et les répliques de lecture gérées de PostgreSQL ou MariaDB partagent la même fonctionnalité 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. Depuis juillet 2026, son auto-scaling, auparavant limité aux conteneurs d’applications puis, depuis mars 2026, aux processus de travail, s’est étendu aux répliques de lecture PostgreSQL et MariaDB : Upsun surveille l’utilisation moyenne du CPU et de la mémoire sur l’ensemble du parc de répliques et ajoute ou retire de la capacité dans les limites définies par l’équipe, sans redémarrage. 

L’instance principale de la base de données en lecture-écriture continue de s’adapter 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 horizontale automatique pour les applications, les workers et les répliques de lecture PostgreSQL ou MariaDB, selon les mêmes 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 d’applications complet et qui souhaitent que la charge de la base de données, très gourmande en lectures, s’adapte automatiquement aux niveaux de leurs applications et de leurs workers, sans avoir à faire appel à un fournisseur de bases 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 d’évolutivité de la base de données à un seul hyperscaler

Inconvénients :

• La mise à l'échelle automatique concerne les répliques de lecture, 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 des répliques de 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 Postgres sous une charge variable, et qui hébergent leur application ailleurs.

Avantages :

• La mise à l'échelle automatique de la puissance de calcul est au cœur du produit Neon, ce n'est 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 appli
• La plage d’auto-scaling du forfait « Launch » plafonne à 8 CU ; le forfait « Scale » fait passer ce plafond à 16 CU, avec des tailles fixes (sans auto-scaling) 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, les migrations de schéma sans blocage et l’auto-scaling automatique des disques, Vitess gérant le partitionnement horizontal au niveau de la couche de stockage. L’auto-scaling 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 MySQL
• Mise à l'échelle automatique des disques, avec augmentation des volumes sur place en mode par défaut
• Migrations de schémas sans blocage grâce à un processus de type « branch-and-deploy-request »
• Répliques de lecture et mise en commun automatisée des connexions

Idéal pour : les équipes qui utilisent MySQL, qui s’attendent à ce que le volume d’écriture finisse par dépasser la capacité d’un seul serveur principal, et qui veulent une solution de partitionnement ne nécessitant pas de refonte de l’architecture par la suite.

Avantages :

• Le partitionnement Vitess a fait ses preuves depuis longtemps en production à très grande échelle
• L'auto-scaling du disque 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 :

• Son point fort, 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, c'est un service de base de données plutôt qu'un hébergeur d'applications.

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, ce n’est pas une étape de configuration à part.

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 sans partitionnement manuel.

Avantages :

• S'adapte automatiquement sans qu'il faille 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 mise en production 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, elle n’héberge pas la couche applicative.

AWS Aurora Serverless v2

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

Une équipe définit une fourchette 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. Le RDS standard pour Postgres, en dehors de la configuration Serverless v2, ne redimensionne pas automatiquement la puissance de calcul : pour changer de taille, il faut modifier la classe d’instance de la base de données, ce qui provoque une brève interruption pendant l’opération de modification.

Principales fonctionnalité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 de l’auto-scaling 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 multicloud ou 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 l’instance

Render

La solution full-stack la plus proche de l’expérience développeur propre à Railway, 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 comme des types de services à part entière. La mise à l’échelle de la base de données se fait par 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 quand 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.

Fonctionnalités clé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 en tant que 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 option

Idéal pour : les équipes qui recherchent avant tout une version plus aboutie de l’expérience Railway 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 :

• Modèle « full-stack » familier, proche de ce à quoi s'attend déjà un utilisateur de Railway
• La tarification par forfait est facile à prévoir
• Postgres et Redis gérés sans avoir besoin d’un fournisseur distinct

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

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 : les applications, les workers et les répliques de lecture de la base de données dans un seul modèle à mise à l’échelle automatique et sur une seule facture, ce qui est super important pour les équipes qui ne veulent pas faire appel à un fournisseur de base de données séparé juste pour combler le fossé de mise à l’échelle. 

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 correspond le mieux à l’expérience de Railway, et le compromis honnête, 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 (FAQ)

Est-ce que Railway gère automatiquement la mise à l’échelle de ses bases de données gérées ?

Pas automatiquement. Les conteneurs d’applications de Railway s’adaptent verticalement jusqu’aux limites du forfait de leur propre chef, et l’évolutivité horizontale des applications est disponible via l’API publique si une équipe développe son propre système d’évolutivité automatique. Ses services gérés Postgres, MySQL, Redis et MongoDB s’adaptent différemment : les volumes de disque sont redimensionnés manuellement via le tableau de bord, et les augmentations de puissance de calcul verticales au-delà des limites du forfait standard font l’objet d’un accord de dépenses engagées avec l’équipe de Railway.

Quelle alternative à Railway permet de mettre automatiquement à l'échelle Postgres ?

Neon adapte automatiquement la puissance de calcul de Postgres dans une plage configurable par branche, y compris la réduction à 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 gère automatiquement la taille 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’être dimensionnée verticalement via une configuration manuelle, comme avant. Ce sont les charges de travail à forte intensité de lecture qui bénéficient directement du nouveau comportement d’auto-scaling.

Est-ce que PlanetScale ou Neon convient le mieux à une équipe qui quitte Railway ?

Ç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 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.

Est-ce qu’Aurora Serverless v2 est un bon choix pour une équipe qui abandonne Railway ?

C’est une solution particulièrement adaptée aux équipes qui utilisent déjà, ou qui souhaitent passer à, l’infrastructure AWS de manière plus générale. Aurora Serverless v2 adapte automatiquement la puissance de calcul dans une plage d’ACU et, sur les versions de moteur prises en charge, peut se mettre en pause à 0 ACU en cas d’inactivité. Ça ne remplace pas l’hébergement d’applications de Railway, et ça n’offre pas la flexibilité multicloud, puisque ça fonctionne uniquement sur AWS.

Est-ce qu’une équipe peut migrer de Railway vers ces alternatives sans avoir à réécrire son code ?

En général, ça se fait avec des changements de configuration plutôt qu’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. Passer à Upsun implique d’ajouter un fichier de configuration YAML décrivant l’application et ses services. Passer à une plateforme exclusivement basée sur une 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.