Railway ou Render : une application inactive peut inverser la facture

Une API qui reçoit peu de requêtes peut coûter moins cher sur Railway, car sa facture suit le CPU et la mémoire effectivement utilisés. Un worker occupé en continu peut, à l’inverse, revenir moins cher sur une instance Render dont le prix mensuel est fixé à l’avance. Le choix dépend donc de la charge moyenne, des ressources nécessaires aux pointes et des données envoyées vers Internet.

L’inactivité entre deux requêtes ne fait pas disparaître la consommation de mémoire. Les trois simulations qui suivent distinguent CPU moyen, RAM moyenne et trafic sortant ; elles supposent des services en ligne pendant un mois complet. Leurs charges sont des hypothèses de calcul, pas des mesures réalisées sur les plateformes.

Les postes à mettre dans la même équation

La tarification de Railway mesure les ressources à la seconde : ses équivalents mensuels sont d’environ 20 $ par vCPU utilisé, 10 $ par Go de RAM occupé et 0,15 $ par Go de volume, auxquels s’ajoutent 0,05 $ par Go sortant. Le plan Hobby coûte au minimum 5 $ par mois et comprend 5 $ de crédits d’usage. Pour les charges envisagées ici, la facture est donc le montant le plus élevé entre 5 $ et la consommation calculée, sans ajouter deux fois le crédit.

La grille de Render combine un espace Hobby à 0 $ ou Pro à 25 $ par mois, le calcul de chaque service et les dépassements mesurés. Les services web et workers payants commencent à 7 $ par mois ; le palier de 1 CPU et 2 Go coûte 25 $. Une petite instance Postgres coûte 6 $ par mois, avec un stockage facturé à 0,30 $ par Go. Render inclut 5 Go de bande passante dans Hobby et 25 Go dans Pro, puis facture 0,15 $ par Go supplémentaire.

Les prix Render sont ajustés au temps pendant lequel une instance payante fonctionne. Dans ces simulations, chaque service reste actif tout le mois : une période sans requêtes ne suspend pas à elle seule son instance. Les calculs utilisent un seul espace Hobby, des dollars américains, aucun service caché et aucun frais fiscal. Ils excluent aussi les besoins de sauvegarde, de réplication ou de calcul supplémentaire qui ne sont pas décrits.

API peu sollicitée : le coût des pointes diffère du coût moyen

Supposons une API accessible tout le mois. Elle atteint parfois 1 CPU et 1,5 Go de RAM, mais sa consommation moyenne est de 0,1 vCPU et 0,4 Go de RAM ; elle envoie 2 Go vers Internet et n’utilise ni volume ni base de données. Les capacités des plans Render placent le petit service web à 0,5 CPU et 512 Mo, et le suivant à 1 CPU et 2 Go. Seul le second couvre les pointes supposées de cette API.

Sur Railway, le CPU moyen représente 2 $, la RAM 4 $ et le trafic 0,10 $, soit 6,10 $ pour le mois. Sur Render Hobby, le service web revient à 25 $ et le trafic reste dans le quota inclus. À charge et capacité de pointe supposées identiques, l’écart est de 18,90 $ en faveur de Railway. Le service doit néanmoins tenir dans les limites de ressources retenues pour chaque plateforme.

Changeons seulement la mémoire moyenne : si l’API conserve 2 Go occupés même entre les requêtes, ce poste atteint 20 $ sur Railway. Avec le même CPU moyen et les mêmes 2 Go sortants, le total devient 22,10 $. La fréquence des appels n’a pas bougé, mais l’avantage face à l’instance Render de 25 $ s’est presque effacé. Une application silencieuse n’est donc économique à l’usage que si son empreinte mémoire reste également modeste.

Worker continu : une petite instance peut prendre l’avantage

Supposons maintenant un worker actif pendant tout le mois, sans base ni volume, qui utilise en moyenne 0,4 vCPU et 0,4 Go de RAM. Ses pointes restent sous 0,5 CPU et 512 Mo, et son trafic sortant vers Internet est nul dans cet exemple. Il peut ainsi fonctionner sur la petite instance de worker Render, sans supposer qu’une moyenne située au bord de sa capacité suffirait à absorber toutes les pointes.

Le calcul Railway donne 8 $ de CPU et 4 $ de RAM, soit 12 $ par mois. L’instance Render coûte 7 $ pour le mois complet : Render est ici moins cher de 5 $. Ce résultat tient au fonctionnement continu du worker et à sa capacité à rester dans ce petit palier. Si une file de tâches impose davantage de RAM ou de CPU aux heures chargées, il faut choisir une instance Render plus grande ; si le worker ne tourne qu’à certaines périodes, son temps d’exécution change aussi le calcul.

Application et Postgres : deux consommations distinctes

Troisième hypothèse : une application web atteint parfois 1 CPU et 1,5 Go de RAM, mais consomme en moyenne 0,2 vCPU et 0,8 Go. Une base PostgreSQL séparée reste en ligne avec 0,05 vCPU et 0,2 Go de RAM moyens ; on suppose que ses pointes tiennent dans 0,1 CPU et 256 Mo. La base dispose de 5 Go de stockage. L’ensemble envoie 50 Go vers Internet durant le mois, sans worker ni cache supplémentaire.

Sur Railway, l’application coûte 12 $ de CPU et de RAM ; la base ajoute 3 $ de ressources, le volume 0,75 $ et le trafic 2,50 $. Le total hypothétique est de 18,25 $. Sur Render Hobby, l’instance web coûte 25 $, la petite instance Postgres 6 $ et ses 5 Go de stockage 1,50 $. Après les 5 Go sortants inclus, les 45 Go supplémentaires coûtent 6,75 $ : le total est de 39,25 $.

Dans cette configuration, Railway garde 21 $ d’avance. La petite empreinte mémoire attribuée à PostgreSQL est toutefois déterminante : connexions, cache et croissance des données peuvent accroître sa consommation sur Railway ou rendre nécessaire un palier de base supérieur sur Render. Le CPU et la RAM de l’application ne doivent pas être confondus avec ceux de la base, car chaque service contribue séparément à la facture.

Le point de bascule dépend de la RAM et du trafic

Le comparatif de Ployz chiffre un service de 1 CPU et 2 Go à 25 $ sur Render contre 40 $ sur Railway si ces deux ressources sont utilisées entièrement pendant un mois. Son seuil d’environ 63 % correspond à 25 ÷ 40 : il suppose que CPU et RAM diminuent dans la même proportion et écarte le trafic. Les performances d’un CPU Render et d’un vCPU Railway ne sont pas garanties identiques ; ce seuil est un repère de prix, pas un résultat de performance.

Une mémoire qui reste pleine déplace fortement ce seuil. Pour un service conservant 2 Go de RAM, la mémoire coûte déjà 20 $ sur Railway. Sans trafic, il ne reste que 5 $ de CPU avant d’atteindre les 25 $ de l’instance Render, soit 0,25 vCPU moyen. L’API de la première simulation est proche de cette situation après le changement de mémoire, malgré ses rares requêtes.

Le trafic sortant déplace à son tour l’écart : les règles de bande passante de Render comptent les réponses envoyées sur Internet et facturent 0,15 $ par Go au-delà du quota, tandis que les échanges privés entre services Render d’une même région n’y entrent pas. Dans les hypothèses précédentes, les 2 Go de l’API restent sous le quota Hobby, alors que les 50 Go de l’application avec base produisent un dépassement. Le tarif Railway de 0,05 $ par Go rend cet écart plus sensible lorsque les sorties augmentent.

Le coût d’équipe modifie aussi la comparaison

Les trois simulations reposent sur les espaces Hobby. Pour une équipe qui a besoin des fonctions Pro, Railway applique un minimum mensuel de 20 $ incluant autant de crédits d’usage ; Render ajoute l’abonnement Pro de 25 $ au calcul des services, mais porte son quota sortant à 25 Go. En reprenant exactement l’application avec base de la troisième simulation, la consommation Railway de 18,25 $ aboutirait donc au minimum de 20 $. Sur Render Pro, les mêmes services et le stockage totaliseraient 32,50 $, puis 3,75 $ pour les 25 Go sortants au-delà du quota, auxquels s’ajoutent 25 $ d’espace de travail : 61,25 $.

Le prix ne résume pas les fonctions obtenues. Render Pro ouvre notamment les prévisualisations complètes et l’autoscaling horizontal ; Railway Pro augmente les limites de ressources, la capacité de collaboration et la durée de conservation des journaux. Pour une petite équipe SaaS ou une agence, la comparaison utile porte donc sur les services réellement nécessaires, leurs moyennes de CPU et de RAM, leurs pointes, le trafic sortant et les fonctions d’exploitation requises. C’est cet ensemble, plutôt que le seul prix affiché pour une instance, qui détermine la plateforme la moins coûteuse pour la charge envisagée.

À lire aussi :

• OVHcloud ou Scaleway : le produit comparé peut inverser l’écart de prix
• Patreon abandonne le paiement par création : l’inaction peut geler les revenus
• Supabase ou Firebase : SQL et facturation à l’usage changent le risque