Railway Hosting oder Render? Der Vergleich 2026

Railway Hosting oder Render: Entscheidend ist, ob der tatsächliche Ressourcenverbrauch abgerechnet oder eine feste Rechenkapazität gebucht werden soll. Im Beispiel einer kleinen App weiter unten kostet Railway Hobby $15.11 im Monat, Render Hobby $20. Bei Render ist allerdings die Datenbankwiederherstellung enthalten, die in der Railway-Kalkulation fehlt. Railway passt zu einem flexiblen Ressourcenbedarf; Render ist die bessere Wahl, wenn planbare Instanzkosten und eine enthaltene Postgres-Wiederherstellung wichtiger sind.

Railway Hosting vs. Render: Welche Plattform passt?

Render empfiehlt sich für Gründer, die eine dauerhaft laufende App, einen Hintergrund-Worker und eine kostenpflichtige Postgres-Datenbank samt Wiederherstellung suchen. Ein Worker ist ein separater Prozess, der etwa E-Mails verschickt oder Berichte erstellt, ohne Besucher warten zu lassen. Für jeden Dienst wird bei Render eine feste Rechenkapazität ausgewählt. Die Grundkosten lassen sich dadurch gut kalkulieren.

Railway passt, wenn mehrere Dienste flexibel betrieben werden sollen und die Bereitschaft besteht, ihren Ressourcenverbrauch im Blick zu behalten. Die App-Hosting-Plattform rechnet die CPU-Leistung und den Arbeitsspeicher ab, die die Dienste tatsächlich nutzen. Ihre grafische Projektübersicht macht die Verbindungen zwischen App, Worker und Datenbank nachvollziehbar. Eine geringe CPU-Auslastung kann Kosten sparen, auch wenn die Dienste durchgehend laufen.

Für kleine Teams lohnt sich neben dem Vergleich der Instanzen auch ein Blick auf die Workspace-Tarife. Bei Railway Pro deckt der Mindestbetrag bereits Ressourcenverbrauch ab; bei Render Pro kommt die Workspace-Gebühr zu den Rechenkosten hinzu. Wer allein gründet, kann beide Hobby-Workspaces in die Auswahl einbeziehen. Ein günstiges Deployment bedeutet allerdings noch lange nicht, dass die Datenbank für den Produktivbetrieb eingerichtet ist.

Preise und Funktionen wurden am 18. Oktober 2026 anhand der aktuellen Preisseiten und Dokumentationen beider Anbieter geprüft. Die Bewertung berücksichtigt Abrechnungsmodell, Voreinstellungen zur Wiederherstellung, Verhalten von Hintergrundaufgaben und Skalierungsoptionen. Die Beispielrechnung basiert auf den veröffentlichten Tarifen und ausdrücklich genannten Annahmen; sie ist weder ein Deployment-Test noch ein Leistungsbenchmark.

Die Grundlagen dieser Unterschiede erläutern die Postgres-Dokumentation von Railway, die Dokumentation zur Wiederherstellung bei Render und die weiter unten beschriebenen Skalierungsregeln beider Plattformen.

Render Hosting und Railway: Was kostet dieselbe kleine App?

Bei der modellierten App mit geringer CPU-Auslastung ist Railway günstiger. Bei Render steht die Zwischensumme für Rechenressourcen schon vor dem Start fest. Daraus folgt nicht, dass eine Plattform grundsätzlich günstiger wäre. Railway misst den Verbrauch. Render berechnet die ausgewählte Instanz während ihrer Laufzeit; bei kürzerer Nutzung wird anteilig abgerechnet.

Die aktuelle Tarifstaffel von Railway umfasst Free für $0, Hobby mit einem monatlichen Mindestbetrag von $5, Pro mit einem Mindestbetrag von $20 und Enterprise zu individuellen Preisen. Bei Hobby und Pro ist der jeweilige Mindestbetrag als Ressourcenverbrauch enthalten. Pro umfasst unbegrenzt viele Workspace-Mitglieder. Railway-Preise.

Die aktuellen Workspace-Tarife von Render sind Hobby für $0, Pro für $25 im Monat, Scale für $499 und Enterprise zu individuellen Preisen. Rechenressourcen werden separat berechnet. Pro umfasst unbegrenzt viele Mitglieder; die Gebühr fällt nicht pro Entwickler an. Hobby enthält 5 GB Datentransfer, Pro 25 GB. Darüber hinaus kostet der Datentransfer $0.15 pro GB. Render-Preise.

Annahmen zur Auslastung

Als Beispiel dient eine kleine Buchungs-App eines Gründers. Sie besteht aus einem Web-/API-Dienst, einem dauerhaft laufenden Worker, der Aufträge über die vorhandene Postgres-Datenbank verarbeitet, und einem Postgres-Dienst mit einem einzelnen Knoten. Benötigt die Warteschlange einen separaten Cache, entstehen zusätzliche Kosten. Ein solcher Cache ist in diesem Beispiel nicht vorgesehen.

Der Modellmonat hat 30 Tage oder 2,592,000 Sekunden. Alle Dienste laufen durchgehend. Der durchschnittlich abgerechnete Arbeitsspeicher beträgt 0.5 GB für den Webdienst, 0.5 GB für den Worker und 0.25 GB für Postgres: insgesamt 1.25 GB. Die durchschnittliche aktive CPU-Nutzung liegt entsprechend bei 0.05, 0.05 und 0.02 vCPU: insgesamt 0.12 vCPU. Eine vCPU ist eine Einheit für Rechenkapazität. Ein Durchschnitt von 0.12 beschreibt die über den Monat geleistete CPU-Arbeit, keine Instanz mit dieser ausgewiesenen Größe.

Angenommen werden außerdem eine Datenbank-Volume-Belegung von 1 GB über den gesamten Monat und 1 GB ausgehender Internet-Datenverkehr. Datenbankverbindungen bleiben im privaten Netzwerk, Builds innerhalb der enthaltenen Kontingente. Replikas, Staging-Umgebungen, zusätzliche Festplatten und Hochverfügbarkeitsknoten gibt es nicht. Steuern, Domainregistrierung und Gebühren für von der App genutzte APIs sind nicht berücksichtigt.

Bei Render fällt die Wahl auf die Webinstanz 0.5c-512mb für $7, einen weiteren Worker mit 0.5c-512mb für $7 und die Postgres-Instanz 0.1c-256mb für $6. Laut Preisseite ist 1 GB Datenbankspeicher enthalten; auch die Dokumentation zur Erstellung erlaubt diese Anfangsgröße. Die Instanzen sind bewusst sehr klein gewählt. Das ist keine Empfehlung, jede produktive App damit zu betreiben. Preise für Rechenressourcen, Konfiguration des Datenbankspeichers.

Verglichen werden dieselben App-Komponenten bei einem angenommenen Bedarf, keine identische Hardwareleistung. Der gemessene Speicher- und CPU-Verbrauch bei Railway fließt als Rechengröße in die Schätzung ein; die Instanzgrößen bei Render bilden Kapazitätsgrenzen. Ob diese Grenzen für die eigene App ausreichen, muss ein Lasttest zeigen.

Die Monatsrechnung im Detail

Railway weist folgende Tarife aus: $0.00000386 pro GB-Sekunde Arbeitsspeicher, $0.00000772 pro vCPU-Sekunde, $0.00000006 pro GB-Sekunde Volume-Speicher und $0.05 pro GB ausgehendem Datenverkehr eines Dienstes. Aus diesen exakt ausgewiesenen Tarifen und den genannten Annahmen ergibt sich folgende Rechnung. Railway-Ressourcenpreise.

Die Ressourcentarife stammen von Railway, die Instanz- und Workspace-Preise von Render. Wie Railway den Mindestbetrag auf den Verbrauch anrechnet, beschreibt die Tarifdokumentation. Für die Summen werden ungerundete Zwischenwerte verwendet. Die gerundeten monatlichen Referenztarife von Railway ergeben geringfügige Cent-Abweichungen; hier wird für den Monat mit 30 Tagen durchgehend mit den ausgewiesenen Sekundenpreisen gerechnet.

Ab welcher Auslastung wird Render günstiger?

In diesem Hobby-Vergleich wird Render ab einer durchschnittlichen aktiven CPU-Nutzung von etwa 0.364 vCPU über alle drei Dienste günstiger, sofern jeder Dienst weiterhin in seine ausgewählte Render-Instanz passt. Bleiben Arbeitsspeicher, Volume-Belegung, Datentransfer und Instanzzahl unverändert, betragen die monatlichen Ressourcenkosten bei Railway $12.71192 + $20.01024 × durchschnittliche aktive vCPU. Der Schnittpunkt ergibt sich, wenn dieser Ausdruck den $20 von Render entspricht.

Bei 0.12 vCPU kostet Railway $15.11. Bei 0.30 sind es $18.71, bei 0.50 $22.72 und bei 0.70 $26.72. Render bleibt nur dann bei $20, wenn die gewählten Instanzen die Last bewältigen. Das sind Berechnungen zur Kostenentwicklung bei veränderter Auslastung, keine Leistungsmessungen oder Schätzungen zu Anfragen pro Sekunde.

Auch ohne zusätzliche Besucher kann mehr Arbeitsspeicher die Rechnung erhöhen. Jedes zusätzliche GB, das über diesen Modellmonat im Durchschnitt belegt wird, verursacht bei Railway etwa $10.01 an Ressourcenkosten, bevor sich Tarifmindestbeträge auswirken. Ein Worker kann auch beim Warten auf Aufträge Speicher belegen. „Untätig“ heißt deshalb nicht „kostenlos“.

Bei der Planbarkeit liegt Render vorn. Solange Instanzgrößen und -zahl gleich bleiben, steht die Zwischensumme für Rechenressourcen fest. Datentransfer, Builds über den Freikontingenten und wachsender Speicherbedarf müssen separat eingeplant werden. Bei Railway helfen Verbrauchswarnungen und der Blick auf die tatsächliche Nutzung. Ein hartes Ausgabenlimit für Rechenressourcen schaltet die Dienste ab. Es bremst Ausgaben, ermöglicht aber keinen unbegrenzten Traffic zum Festpreis.

Kostenlose Tarife: Zum Testen geeignet, für diesen Stack begrenzt

Für eine kostenlose Webdemo liegt Render vorn. Für den vollständigen Stack im Produktivbetrieb ist keines der Gratisangebote eine tragfähige Standardlösung. Render bietet pro Workspace und Kalendermonat 750 kostenlose Webinstanzstunden. Ein kostenloser Webdienst schläft allerdings nach 15 Minuten ohne eingehenden Traffic ein. Die kostenlose Postgres-Datenbank läuft nach 30 Tagen ab; für Hintergrund-Worker und Cronjobs gibt es keine kostenlosen Instanztypen. Grenzen der kostenlosen Render-Dienste.

Railway bietet inzwischen einen dauerhaften Free-Tarif. Neue Konten erhalten einmalig $5 Testguthaben, das bis zu 30 Tage gilt; anschließend gibt es jeden Monat $1 Gratisguthaben. Kostenlose Dienste haben engere Grenzen für Arbeitsspeicher und Volumes. Cron ist in diesem Tarif nur während der Testphase verfügbar. Das wiederkehrende Guthaben ist ein kleines Kontingent, keine Zusage, beliebige Apps mit drei Diensten kostenlos zu hosten. Details zum kostenlosen Railway-Tarif.

Bei einer Demo kann eine Schlafpause vertretbar sein. Wenn ein Kunde einen kostenpflichtigen Termin buchen möchte, sind eine erst aufwachende App oder eine abgelaufene Datenbank der falsche Kompromiss. Die kostenpflichtige Dienstkonfiguration muss gezielt gewählt werden: Ein Upgrade des Render-Workspaces allein stellt einen kostenlosen Dienst noch nicht auf einen kostenpflichtigen Instanztarif um.

Managed Postgres: Render punktet mit enthaltener Wiederherstellung

Render passt, wenn die Wiederherstellung schon bei einer kleinen kostenpflichtigen Datenbank enthalten sein soll. Railway lohnt sich, wenn eine anpassbare Datenbankinfrastruktur die zusätzlichen Entscheidungen rechtfertigt. PostgreSQL, meist Postgres genannt, ist die relationale Datenbank, in der etwa Benutzer, Bestellungen und Buchungen gespeichert werden.

Render sichert kostenpflichtige Postgres-Instanzen fortlaufend für die zeitpunktgenaue Wiederherstellung. Damit lassen sich Daten auf einen früheren Stand zurücksetzen. Das Wiederherstellungsfenster beträgt bei Hobby-Workspaces 3 Tage, ab Pro 7 Tage. Eine Wiederherstellung erzeugt eine separate Datenbank, die geprüft wird, bevor die Verbindungsdaten der App umgestellt werden. Wiederherstellung und Exporte bei Render.

Die aktuelle Postgres-Vorlage von Railway wird von Railway gepflegt. Hinzu kommen eine eigene Umstellung auf Hochverfügbarkeit und eine optionale zeitpunktgenaue Wiederherstellung. Das gesamte Angebot als „Unmanaged Postgres“ zu bezeichnen, würde diesen Unterschied unterschlagen. Änderungen am Image, am Startbefehl oder an den Variablen der Vorlage können die Betriebsverantwortung allerdings wieder auf den Nutzer übertragen. Umfang des Postgres-Angebots von Railway.

Die Wiederherstellungsfunktion von Railway muss aktiviert werden. Sie archiviert in einem Storage-Bucket und berechnet sowohl den Archivspeicher als auch den ausgehenden Upload-Datenverkehr der Datenbank. Laut Postgres-Dokumentation reicht der Wiederherstellungsverlauf ungefähr vier Wochen zurück, sobald das Archiv entsprechend angewachsen ist. Das kann nützlich sein, unterscheidet sich aber bei Einrichtung und Abrechnung vom enthaltenen Wiederherstellungsfenster bei Render. Zeitpunktgenaue Wiederherstellung bei Railway.

Wiederherstellung ist kein automatisches Failover

Backups helfen bei Datenverlust, Hochverfügbarkeit beim Ausfall eines Datenbankknotens. Löscht eine fehlerhafte Migration Buchungen, kann ein Standby-System dieselbe Löschung übernehmen. Dann wird ein früherer, wiederherstellbarer Datenstand benötigt. Fällt dagegen die primäre Datenbank aus, kann ein Standby-System übernehmen, ohne die Datenbank erst aus einem Archiv rekonstruieren zu müssen.

Renders Hochverfügbarkeitskonfiguration (HA) setzt einen Postgres-Instanztarif mit mindestens 1 CPU voraus. Für die Standby-Instanz gelten dieselben Rechen- und Speichertarife wie für die primäre Datenbank. Die Datenbank für $6 aus dem Beispiel erfüllt diese Voraussetzung nicht. HA-Voraussetzungen bei Render.

Railways Umstellung auf Hochverfügbarkeit (HA) ergänzt Datenbankreplikas, Koordinationsdienste und Verbindungsproxies. Die automatische Umstellung unterstützt offizielle Postgres-Images von Railway. Angepasste Images wie PostGIS oder TimescaleDB sind mit diesem Verfahren nicht kompatibel. Für eine App, deren Datenbank solche Images benötigt, ist das eine wesentliche Einschränkung. HA-Voraussetzungen bei Railway.

Die kleinen Tarife haben konkrete Obergrenzen: Railway Hobby begrenzt Volume-Speicher auf 5 GB. Die im Beispiel gewählte Postgres-Instanz von Render verfügt über 256 MB RAM und erlaubt höchstens 100 Verbindungen. Ein wachsender Datenbestand oder eine App mit vielen Datenbankverbindungen kann eine andere Konfiguration erzwingen, bevor die CPU-Kosten den Ausschlag geben. Railway-Limits, Render-Datenbankgrößen.

Für Gründer lautet die praktische Frage: Wer bemerkt ein Problem, stellt die Daten wieder her und prüft, ob die Buchungen stimmen? Die Wiederherstellungskonfiguration muss sich im eigenen Betrieb beherrschen lassen. Ein Probelauf gehört dazu, bevor unersetzliche Daten gespeichert werden.

Hintergrund-Worker und Cron: Render bietet klarere Jobsteuerung

Render ist die übersichtlichere Wahl für Teams, die Webdienste, Worker und zeitgesteuerte Jobs als eigene Diensttypen definieren möchten. Hintergrund-Worker laufen dort durchgehend und verarbeiten Aufträge aus einer Warteschlange, ohne eingehenden Netzwerkverkehr anzunehmen. Auch Railway kann einen Worker als dauerhaft laufenden Dienst ohne öffentlichen Endpunkt betreiben. Ein eigener Produktname ist keine Voraussetzung für einen Hintergrundprozess. Worker bei Render, Dienstmodell von Railway.

Ein Worker eignet sich für Aufgaben, die über den Tag verteilt eintreffen, etwa den Versand einer Buchungsbestätigung. Cron startet dagegen einen Befehl nach Zeitplan, beispielsweise für einen nächtlichen Bericht. Ein Worker, der ständig nach neuen Aufträgen fragt, verbraucht Ressourcen anders als ein kurz laufender geplanter Job. Die Kosten des einen lassen sich deshalb nicht einfach auf den anderen übertragen.

Railway bietet integrierte Cron-Zeitpläne in den Diensteinstellungen. Zwischen Ausführungen müssen mindestens 5 Minuten liegen, Zeitpläne verwenden UTC, und ein Job muss sich nach Abschluss beenden. Lässt er eine Datenbankverbindung offen und bleibt aktiv, überspringt Railway die nächste geplante Ausführung. Cron-Regeln bei Railway.

Auch Render verwendet UTC. Eine geplante Ausführung wird verschoben, solange die vorherige noch läuft. Nach 12 Stunden beendet Render einen Lauf. Pro Cron-Dienst gilt ein monatlicher Mindestbetrag von $1; die Rechenzeit wird sekundengenau abgerechnet. Wird ein Lauf manuell gestartet, bricht Render zuerst den aktiven Lauf ab. Cron-Verhalten bei Render.

Ob ein Lauf übersprungen oder verschoben wird, kann bei einem nächtlichen Datenabgleich entscheidend sein. Jobs sollten sich gefahrlos wiederholen lassen, ihren Abschluss protokollieren und bei fehlenden Ergebnissen eine Warnung auslösen. Die Hosting-Plattform startet den Befehl. Ob die eigentliche Geschäftsaufgabe abgeschlossen wurde, muss die App weiterhin selbst feststellen.

Railways optionale Serverless-Einstellung versetzt einen Warteschlangen-Worker nicht zwangsläufig in den Ruhezustand. Datenbankverbindungen und anderer ausgehender Traffic können das Einschlafen verhindern. Beim Aufwecken entsteht zudem ein Kaltstart. Ein Prozess, der ständig nach Aufträgen fragt, bleibt unter Umständen dauerhaft aktiv. Serverless-Verhalten bei Railway.

Regionen und Skalierung: Welche Grenzen sind entscheidend?

Railway liegt vorn, wenn Replikas eines Dienstes auf mehrere Regionen verteilt werden sollen. Render punktet, wenn sich die Replikazahl automatisch nach CPU- oder Speicherzielen richten soll. Vertikale Skalierung bedeutet, einer Instanz mehr Ressourcen zu geben. Horizontale Skalierung bedeutet, mehr Instanzen zu betreiben. Beide Ansätze lösen unterschiedliche Engpässe.

Bei Railway wächst die Ressourcennutzung automatisch bis zu den konfigurierten Grenzen; die Zahl horizontaler Replikas wird manuell festgelegt. Bei Replikas in mehreren Regionen wird öffentlicher Traffic zur nächstgelegenen Region geleitet. Bei Render muss für mehr Ressourcen pro Instanz ein größerer Instanztarif gewählt werden. Ab Pro können Workspaces die Instanzzahl automatisch an Zielwerten für CPU- oder Speicherauslastung ausrichten. Skalierung bei Railway, Skalierung bei Render.

Railway nennt Kalifornien, Virginia, Amsterdam und Singapur als Regionen. Render nennt Oregon, Ohio, Virginia, Frankfurt und Singapur. Maßgeblich sollte sein, wo Nutzer und Daten sein müssen. Die pauschale Behauptung, ein Anbieter sei grundsätzlich schneller, ist nicht belegt. Railway-Regionen, Render-Regionen.

Bei einer kleinen App sollten API, Worker und Datenbank zunächst am selben Standort laufen. Eine verteilte API verteilt nicht automatisch auch die Schreibvorgänge der Datenbank. Mehr Standorte machen eine datenbankintensive Anfrage deshalb nicht zwangsläufig schneller.

Dabei gibt es praktische Grenzen. Private Netzwerke bei Render sind regional begrenzt. Ein bestehender Dienst oder eine Datenbank kann die Region nicht einfach wechseln; stattdessen müssen Ersatzressourcen angelegt und die Daten migriert werden. Railway erlaubt Regionswechsel, doch bei einem Dienst mit angehängtem Volume sind eine Volume-Migration und Ausfallzeit nötig. Bei Render verhindert eine angehängte persistente Festplatte die Skalierung dieses Dienstes auf mehrere Instanzen. Diese Einschränkungen gehören geklärt, bevor Kunden-Uploads auf der lokalen Festplatte der App landen.

Plattformwechsel: Daten und Betriebsabläufe müssen mitziehen

Ein Wechsel lohnt sich, wenn eine bestätigte Grenze oder wiederkehrende Kosten ihn rechtfertigen. Ein übersichtlicher wirkendes Dashboard allein reicht als Grund nicht aus. Railways grafische Projektübersicht eignet sich für Gründer, die Dienste visuell miteinander verbinden möchten. Renders Diensttypen und Blueprints passen zu Teams, die ihre Infrastruktur reproduzierbar konfigurieren wollen. Beide Plattformen können aus Repositories oder Container-Images deployen, was die Portabilität der App erleichtert. Für Datenbank und Betriebskonfiguration bleibt dennoch eine sorgfältig geplante Migration nötig. Migrationsleitfaden von Render, Migrationsleitfaden von Railway.

1. 1

   Laufende Komponenten erfassen

   Startbefehl des Webdienstes, Worker-Befehl, Cron-Zeitplan, Umgebungsvariablen, Secrets, Datenbankerweiterungen, Speicher und Domains auflisten. Dabei festhalten, welche Jobs während des Umzugs keinesfalls doppelt laufen dürfen.

2. 2

   Datenbankumzug proben

   Die Zieldatenbank anlegen und Export sowie Wiederherstellung testen. Schemakompatibilität, benötigte Erweiterungen, Datensatzanzahl und wichtige Abfragen der App prüfen. Zugangsdaten gehören nicht in die Versionsverwaltung.

3. 3

   Schreibzugriffe für den finalen Umzug planen

   Festlegen, wie Schreibzugriffe während der abschließenden Übertragung angehalten oder synchronisiert werden. Geplante Jobs und Worker bei Bedarf pausieren, damit nicht beide Plattformen dieselbe Bestätigung verschicken oder denselben Betrag abbuchen.

4. 4

   Umschalten und prüfen

   Verbindungszeichenfolgen und Domains aktualisieren, einen echten Anwendungsablauf durchspielen sowie Hintergrundjobs und Wiederherstellungseinstellungen prüfen. Bevor die alten Dienste abgeschaltet werden, muss ein Rückkehrplan bestehen, der neue Schreibvorgänge auf dem Zielsystem berücksichtigt.

Eine zuverlässig laufende App sollte nicht wegen der kleinen Hobby-Ersparnis aus diesem Beispiel umziehen, ohne zuvor Migrationsaufwand und vorübergehende Doppelbetriebskosten zu kalkulieren. Wenn Kundendaten automatisches Failover erfordern, müssen zuerst die erweiterten Datenbankkonfigurationen verglichen werden. Eine einfache Rechnung für drei Dienste reicht für diese Entscheidung nicht aus.

Vercel passt besser, wenn ein Next.js-Frontend mit integrierten Vorschauen für Pull Requests im Mittelpunkt steht. Die Dokumentation zum Next.js-Deployment erklärt diesen Ablauf. Unser Vergleich von Vercel und Netlify und der Leitfaden zu den Vercel-Kosten helfen bei dieser Auswahl.

Fly.io passt besser, wenn Lebenszyklus, Ressourcen und geografische Platzierung virtueller Maschinen direkt gesteuert werden sollen. Welche Möglichkeiten es dafür gibt, beschreibt die Machines-Dokumentation.

Render oder Railway: So fällt die Entscheidung

Render ist der passende Einstieg, wenn eine enthaltene Postgres-Wiederherstellung und ein instanzbasiertes Rechenbudget die wichtigsten Gründe sind, auf eigene Server zu verzichten. Railway passt, wenn die flexible Zusammenstellung von Diensten und eine verbrauchsabhängige Abrechnung stärker zählen. Für eine App mit mehreren Diensten ist Railway eine ernst zu nehmende Render-Alternative. Dann liegen allerdings auch die Verbrauchsannahmen und die Wiederherstellungskonfiguration in der eigenen Verantwortung.

Als nächster Schritt für die kommende Woche bietet sich an, die tatsächlichen Anforderungen an Webdienst, Worker und Datenbank auf das Beispiel zu übertragen. Die angenommenen Werte für Arbeitsspeicher, CPU und ausgehenden Datenverkehr werden durch Messungen einer repräsentativen Auslastung ersetzt. Dazu kommen die benötigten Wiederherstellungseinstellungen. Erst dann werden die Gesamtkosten des jeweiligen Workspaces verglichen. Wer mit einer der Plattformen bereits zufrieden ist, sollte einen Wechsel als geschäftliches Vorhaben mit eigenen Kosten behandeln, nicht als selbstverständliches Upgrade.

Häufige Fragen

Railway vs Render: Was bieten die kostenlosen Tarife?

Kostenlose Webdienste bei Render schlafen nach 15 Minuten ohne Aktivität ein; die kostenlose Postgres-Datenbank läuft nach 30 Tagen ab. Railway bietet zunächst $5 Testguthaben und danach monatlich $1 Gratisguthaben. Keine der Plattformen stellt unbegrenzt kostenlose Ressourcen für diesen vollständigen, dauerhaft laufenden Stack aus Webdienst, Worker und Datenbank bereit.

Railway vs Render: Welche Plattform kostet weniger?

Das ausdrücklich definierte Modell der kleinen App kostet bei Railway Hobby $15.11 und bei Render Hobby $20. Mit den Pro-Workspaces sind es $20 beziehungsweise $45. Das sind berechnete Szenarien, keine allgemeingültigen App-Preise. Wiederherstellungsarchive von Railway sind nicht eingerechnet; bei Render ist die Wiederherstellung der kostenpflichtigen Datenbank enthalten.

Railway oder Render: Was eignet sich besser als Backend?

Beide können eine API, Hintergrundaufgaben und Postgres hosten. Render passt zu Anforderungen an enthaltene Wiederherstellung bei kostenpflichtigen Datenbanken und zielwertgesteuerte horizontale Autoskalierung ab Pro. Railway punktet mit Verbrauchsabrechnung, seiner grafischen Übersicht verbundener Dienste und Replikas in mehreren Regionen. Vor der Wahl von Railways automatischer HA-Umstellung muss die Kompatibilität des Datenbank-Images geprüft werden.