Die besten Railway-Alternativen zur Skalierung von Produktionsdatenbanken im Jahr 2026

Railway ist eine der einfachsten Möglichkeiten, eine App bereitzustellen. Du verbindest ein Git-Repository, pushst das Programmier-Ergebnis, und schon wenige Minuten später läuft ein Service neben einer verwalteten Datenbank. Für Nebenprojekte und Produkte in der Frühphase ist diese Geschwindigkeit kaum zu übertreffen.

Die Lücke zeigt sich auf der Datenbankebene. Die Anwendungscontainer von Railway skalieren bei steigender Nachfrage von selbst vertikal, und horizontale Skalierung ist für Apps verfügbar, wenn ein Team seinen eigenen Autoscaler an die öffentliche API von Railway anbindet. 

Die verwalteten Datenbanken neben diesen Apps – Postgres, MySQL, Redis und MongoDB – werden nicht genauso behandelt. Die Größe der Festplattenvolumes wird manuell über eine Dashboard-Aktion angepasst. Vertikale Rechenkapazitätserweiterungen, die über die Grenzen des Standardtarifs hinausgehen, erfolgen über eine „Committed-Spend“-Vereinbarung, bei der das Railway-Team die Arbeitslast manuell auf dedizierter Hardware bucht. Bei Traffic-Spitzen kann die App-Ebene oft mithalten. Die Datenbank schafft das meist nicht – zumindest nicht, ohne dass es jemand bemerkt und eingreift.

Dieser Leitfaden behandelt die Plattformen, auf die Teams umsteigen, wenn die Datenbank – und nicht die App – der Grund dafür ist, dass sie im Jahr 2026 eine Alternative zu Railway in Betracht ziehen.

Die wichtigsten Erkenntnisse

• Dieser Leitfaden vergleicht Railway mit Plattformen, die ab 2026 eine echte Lösung für die Skalierung der Datenbankebene bieten – nicht nur für die Anwendungsskalierung.
• Upsun eignet sich am besten für Teams, die eine einzige Autoscaling-Funktion für Apps, Worker und verwaltete PostgreSQL- oder MariaDB-Lesereplikate wünschen, ohne einen separaten Datenbankanbieter in den Stack aufzunehmen.
• Speziell entwickelte Datenbankplattformen lösen das Problem auf Datenbankebene gezielt: Neon für serverloses Postgres-Compute, PlanetScale für Vitess-basiertes MySQL-Sharding, CockroachDB Serverless für verteiltes SQL und AWS Aurora Serverless v2 für Teams, die bereits auf AWS setzen. Bei allen muss das App-Hosting weiterhin separat gelöst werden.
• Render wird als die Full-Stack-Lösung aufgeführt, die der Erfahrung von Railway am nächsten kommt, wobei der Kompromiss klar benannt wird: Die Datenbank skaliert nach einem von dir gewählten Tarif, nicht automatisch.

Worauf du bei einer auf Datenbankskalierung fokussierten Railway-Alternative achten solltest

• Automatische Skalierung der Datenbank versus manuelle Größenanpassung. Ob Rechenleistung, Speicherplatz oder die Anzahl der Replikate sich automatisch an die Auslastung anpassen, oder ob Skalierung bedeutet, eine größere Instanzgröße auszuwählen und neu bereitzustellen.
• Was tatsächlich automatisch skaliert wird. Manche Plattformen skalieren die primäre Lese-Schreib-Instanz automatisch. Andere skalieren Lese-Replikate automatisch, während die Primärinstanz weiterhin durch manuelle Konfiguration vertikal skaliert wird. Dieser Unterschied ist bei schreibintensiven Workloads von Bedeutung.
• Full-Stack-Plattform versus reiner Datenbankdienst. Ob die Plattform auch die Anwendung hostet oder ob es sich um eine Datenbank handelt, mit der du dich von einer anderswo gehosteten App aus verbindest.
• Multi-Cloud- und BYOC-Unterstützung. Ob die Plattform über AWS, GCP, Azure oder andere Anbieter läuft oder ein Team an eine einzige cloud bindet.
• Preismodell. Ressourcenbasiert, verbrauchsbasiert oder planbasiert – und ob das Modell die richtige Dimensionierung belohnt oder bestraft.
• Compliance. Zertifizierungen wie ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und DSGVO – und ob diese auch Nicht-Produktionsumgebungen abdecken.

Warum die Datenbankebene von Railway an ihre Grenzen stößt

In Railways eigener Dokumentation zur Skalierung werden App-Container beschrieben, die sich automatisch vertikal bis an die CPU- und Speichergrenzen des Tarifs skalieren, sowie eine Replikanzahl für die horizontale Skalierung, die „standardmäßig so bleibt, wie du sie eingestellt hast“ – anpassbar über die öffentliche API, falls ein Team einen eigenen Autoscaler entwickelt. Das ist die App-Ebene.

Die Datenbankebene läuft nach einem anderen Modell. Der Speicher befindet sich auf einem Volume, das durch eine manuelle Live-Größenanpassung im Railway-Dashboard vergrößert wird – nicht automatisch. Die Anhebung vertikaler Rechenleistungsgrenzen für eine Datenbank über die Standard-Ressourcenebene hinaus wird als „Business Class“-Vereinbarung behandelt: eine fest zugesagte monatliche Ausgabe, bei der das Railway-Team die Arbeitslast manuell auf seiner Hardware bucht, wie aus mindestens einer dokumentierten Support-Interaktion mit Railway hervorgeht. 

Nichts davon ist ungewöhnlich für eine „Developer-First“-PaaS. Es bedeutet jedoch, dass bei einem Traffic-Anstieg, der die Datenbank statt der App betrifft, die Reaktion ein Support-Gespräch oder ein Klick im Dashboard ist – und keine automatische Anpassung.

Die besten Railway-Alternativen für die Skalierung von Datenbanken im Jahr 2026

Upsun

Eine Multi-Cloud-Anwendungsplattform, auf der Apps, Hintergrundprozesse und verwaltete PostgreSQL- oder MariaDB-Lese-Replikate dieselbe Autoscaling-Funktion nutzen.

Upsun führt Anwendungen über AWS, GCP, Azure, OVHcloud und IBM Cloud hinweg aus einem einzigen Git-gesteuerten Workflow aus. Seit Juli 2026 wurde die automatische Skalierung, die zuvor auf Anwendungscontainer und seit März 2026 auf Worker-Prozesse beschränkt war, auf PostgreSQL- und MariaDB-Lese-Replikate ausgeweitet: Upsun überwacht die durchschnittliche CPU- und Speicherauslastung über die gesamte Replikatflotte hinweg und fügt Kapazitäten innerhalb der vom Team konfigurierten Schwellenwerte hinzu oder entfernt sie – ganz ohne Neustart. 

Die primäre Lese-Schreib-Datenbankinstanz wird nach wie vor vertikal durch manuelle Konfiguration skaliert, so wie es schon immer der Fall war; was sich geändert hat, ist, dass die Lese-Replikat-Ebene keinen separaten Operator oder ein manuelles Ticket zur Größenanpassung mehr benötigt, um mit leseintensiver Last Schritt zu halten.

Wichtigste Funktionen:

• Horizontale automatische Skalierung für Anwendungen, Worker und PostgreSQL- oder MariaDB-Lese-Replikate – basierend auf denselben CPU- und Speicher-Triggern, die pro Umgebung konfiguriert werden
• Multi-cloud-Bereitstellung über AWS, GCP, Azure, OVHcloud und IBM Cloud
• Katalog mit Managed Services, darunter PostgreSQL, MariaDB, Redis, Elasticsearch, OpenSearch, RabbitMQ und Kafka
• Ressourcenbasierte Preisgestaltung, dimensioniert nach App, Worker und Service
• Konformität mit ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und DSGVO

Am besten geeignet für: Teams, die einen vollständigen Anwendungsstack betreiben und möchten, dass sich die leseintensive Datenbanklast automatisch an ihre App- und Worker-Ebenen anpasst, ohne einen separaten Datenbankanbieter oder einen Kubernetes-Operator einbinden zu müssen.

Vorteile:

• Apps, Worker und Datenbank-Lese-Replikate lassen sich über dieselbe Konsole, CLI oder API skalieren – alles auf einer Rechnung
• Die automatische Skalierung der Lesereplikate fügt Kapazität hinzu oder entfernt sie, ohne dass ein Neustart oder Failover erforderlich ist
• Die Multi-Cloud-Option verhindert, dass die Entscheidung zur Datenbankskalierung an einen einzigen Hyperscaler gebunden ist

Nachteile:

• Die automatische Skalierung gilt für Lesereplikate, nicht für die primäre Schreibinstanz, die weiterhin durch manuelle Konfiguration vertikal skaliert wird.
• Die automatische Skalierung der Datenbank ist in der Produktstufe „Upsun Cloud“ verfügbar; „Upsun Fixed“ unterstützt nur die manuelle Skalierung.

Neon

Eine serverlose Postgres-Plattform, die Rechenleistung und Speicher voneinander trennt, sodass die Rechenleistung pro Zweig unabhängig skaliert werden kann.

Neon läuft mit Standard-Postgres, wobei die Rechenleistung in Compute Units (CU) gemessen wird – jede entspricht etwa einer vCPU und 4 GB RAM. Ein Team legt pro Zweig einen Mindest- und Höchstwert für die CU-Spanne fest, und Neon passt die Rechenleistung innerhalb dieses Bereichs an, wenn sich die Auslastung ändert; bei bestimmten Tarifen wird die Rechenleistung nach einer gewissen Inaktivitätszeit auf null heruntergefahren. Da Speicher und Rechenleistung entkoppelt sind, müssen bei der Aufteilung einer großen Datenbank für eine Vorschau oder einen Migrationstest die zugrunde liegenden Daten nicht kopiert werden.

Wichtigste Funktionen:

• Automatische Skalierung der Rechenleistung innerhalb eines konfigurierbaren CU-Bereichs pro Zweig
• Skalierung auf null nach Inaktivität, mit einem kurzen Kaltstart bei der nächsten Verbindung
• „Copy-on-Write“-Verzweigung für isolierte, produktionsnahe Datenbankkopien
• Rechenleistung der Lesereplik, unabhängig vom automatischen Skalierungsbereich des Primärservers
• Standard-Postgres-Wire-Protokoll, keine proprietäre Abfrageebene

Am besten geeignet für: Teams, deren Engpass speziell die Postgres-Rechenleistung unter variabler Auslastung ist und die ihre Anwendung anderweitig hosten.

Vorteile:

• Die automatische Skalierung der Rechenleistung ist das Kernprodukt von Neon, kein Add-on
• „Scale-to-Zero“ eliminiert Kosten für inaktive Zweigstellen und Preview-Umgebungen
• Da es sich um Standard-Postgres handelt, lassen sich bestehende Treiber, ORMs und Erweiterungen in der Regel übernehmen

Nachteile:

• Neon ist ein Datenbankdienst, kein Anwendungshost – ein Team braucht also weiterhin einen Ort, an dem es seine App ausführen kann
• Der Skalierungsbereich des „Launch“-Tarifs endet bei 8 CU; der „Scale“-Tarif erhöht diese Obergrenze auf 16 CU, wobei darüber hinaus feste, nicht automatisch skalierende Größen für konstante Workloads mit hoher Auslastung verfügbar sind.

PlanetScale

Eine MySQL-kompatible Plattform, die auf Vitess basiert – dem Sharding-System, das ursprünglich zur Skalierung der YouTube-Datenbank entwickelt wurde.

PlanetScale erweitert MySQL um Datenbankverzweigungen, blockierungsfreie Schemamigrationen und automatische Festplatten-Autoskalierung, wobei Vitess das horizontale Sharding auf der Speicherebene übernimmt. Die automatische Festplatten-Skalierung läuft standardmäßig auf NAS-Clustern (Network-Attached Storage) und vergrößert oder verkleinert Volumes innerhalb der Grenzen, die der cloud-Blockspeicher zulässt. PlanetScale bietet auch ein neueres Postgres-Produkt an, das allerdings erst kürzlich hinzugekommen ist – im Gegensatz zu dem auf Vitess basierenden MySQL-Angebot, für das das Unternehmen am bekanntesten ist.

Wichtigste Funktionen:

• Vitess-basiertes automatisches horizontales Sharding für MySQL-kompatible Workloads
• Automatische Skalierung der Festplattenkapazität, standardmäßig mit Vergrößerung der Volumes vor Ort
• Blockierungsfreie Schemamigrationen durch einen „Branch-and-Deploy-Request“-Workflow
• Lese-Replikate und automatisiertes Connection-Pooling

Am besten geeignet für: Teams, die MySQL einsetzen und davon ausgehen, dass das Schreibvolumen irgendwann die Kapazität eines einzelnen Primärservers übersteigt, und die einen Sharding-Ansatz suchen, der später keine Neugestaltung der Architektur erfordert.

Vorteile:

• Vitess-Sharding hat sich im großen Maßstab seit Langem in der Produktivumgebung bewährt
• Automatische Skalierung der Festplattenkapazität und blockierungsfreie Migrationen reduzieren manuelle Datenbankvorgänge
• Durch Branching entsteht ein Git-ähnlicher Workflow für Schemaänderungen

Nachteile:

• Die Kernstärke liegt bei MySQL; Teams, die auf Postgres standardisiert sind, sollten das neuere Postgres-Produkt von PlanetScale mit etablierteren Postgres-spezifischen Optionen abwägen, bevor sie sich festlegen
• Genau wie Neon handelt es sich eher um einen Datenbankdienst als um einen Anwendungshost.

CockroachDB Serverless

Eine verteilte SQL-Datenbank, die mit Postgres kompatibel ist und laut Cockroach Labs Speicherplatz und Transaktionskapazität automatisch skaliert.

CockroachDB Serverless berechnet Gebühren für Speicherplatz und „Request Units“ – eine abstrahierte Maßeinheit für die Abfrageaktivität – und skaliert sowohl nach oben als auch nach unten, ohne dass ein Team im Voraus eine Instanzgröße auswählen muss. Die Daten werden automatisch repliziert, und die bereichsübergreifende Bereitstellung ist direkt in das Produkt integriert und erfordert keinen separaten Konfigurationsschritt.

Wichtigste Funktionen:

• Automatische Skalierung von Speicherplatz und Transaktionskapazität, laut der Produktbeschreibung von Cockroach Labs
• Verbrauchsabhängige Preisgestaltung mit einer kostenlosen Stufe (5 GiB Speicherplatz, 50 Millionen Request Units pro Monat)
• Integrierte bereichsübergreifende Bereitstellung und Datenreplikation
• Postgres-kompatible Treiber, ORMs und SQL-Syntax

Am besten geeignet für: Teams, die eine multiregionale, verteilte Datenbank benötigen und die Skalierung von Speicher und Rechenleistung ohne manuelles Sharding abwickeln möchten.

Vorteile:

• Skaliert automatisch, ohne dass eine Instanzgröße im Voraus festgelegt werden muss
• Multi-Region-Unterstützung und Replikation sind native Bestandteile des Produkts und keine nachträglichen Ergänzungen
• Die kostenlose Stufe eignet sich für den frühen Einsatz in der Produktivumgebung

Nachteile:

• Es handelt sich um eine verteilte SQL-Engine, die das Postgres-Wire-Protokoll verwendet und nicht das Upstream-Postgres selbst. Daher müssen spezifische Erweiterungen, auf die eine App angewiesen ist, anhand der Kompatibilitätsdokumente von CockroachDB überprüft werden
• Wie die anderen reinen Datenbank-Einträge hier hostet sie nicht die Anwendungsschicht.

AWS Aurora Serverless v2

Amazons verwaltete, Postgres- und MySQL-kompatible Datenbank mit einer serverlosen Konfiguration, die die Rechenleistung innerhalb eines festgelegten Bereichs automatisch skaliert.

Ein Team legt einen Mindest- und Höchstbereich für Aurora Capacity Units (ACUs) fest, und Aurora skaliert innerhalb dieses Bereichs, wenn sich die Auslastung ändert. Seit einem Update im November 2024 kann der Mindestwert bei unterstützten Engine-Versionen auf 0 ACUs gesetzt werden, was eine automatische Pause bei Inaktivität und eine automatische Wiederaufnahme bei der nächsten Verbindung ermöglicht. Standard-RDS für Postgres, außerhalb der Serverless v2-Konfiguration, skaliert die Rechenleistung nicht automatisch: Eine Größenanpassung bedeutet eine Änderung der DB-Instanzklasse, was während des Änderungsvorgangs zu einem kurzen Ausfall führt.

Wichtige Funktionen:

• Automatische Skalierung der Rechenleistung innerhalb eines konfigurierbaren ACU-Bereichs
• Automatische Pause auf 0 ACUs bei unterstützten Aurora PostgreSQL- und Aurora MySQL-Versionen
• Tiefe Integration in das übrige AWS-Ökosystem: IAM, VPC, CloudWatch, Secrets Manager
• Automatische Skalierung des Speichers, unabhängig von der Rechenkapazitätskonfiguration

Am besten geeignet für: Teams, die bereits auf AWS setzen und die automatische Skalierung von Datenbanken als verwaltete Funktion innerhalb von RDS nutzen möchten, anstatt einen neuen Datenbankanbieter einzuführen.

Vorteile:

• Die automatische Skalierung im ACU-Bereich ist mittlerweile eine ausgereifte und weit verbreitete AWS-Funktion
• Die automatische Pause senkt die Kosten für zeitweise genutzte Cluster
• Keine neue Anbietergeschäftsbeziehung für Teams, die bereits eine AWS-Infrastruktur betreiben

Nachteile:

• Aurora Serverless v2 ist ausschließlich bei AWS verfügbar und erfüllt daher nicht die Multi-Cloud- oder BYOC-Anforderungen, die manche Teams gleichzeitig umsetzen möchten
• Standard-RDS für Postgres (im Gegensatz speziell zu Aurora Serverless v2) erfordert zur Größenanpassung immer noch eine manuelle, kurzzeitig störende Änderung der Instanzklasse

Render

Die Full-Stack-Lösung, die der Entwicklererfahrung bei Railway am nächsten kommt, mit planbasierten, manuell skalierbaren Datenbanken.

Render erfolgt über Git-Deploys mit Webdiensten, Hintergrund-Workern, Cron-Jobs sowie verwalteten Postgres- und Redis-Instanzen als erstklassige Diensttypen. Die Skalierung der Datenbank erfolgt über die Wahl eines Tarifs: Wähle eine Instanzgröße für CPU, Arbeitsspeicher und Festplatte aus und füge Lesereplikate hinzu, wenn die Leseauslastung entlastet werden muss. Laut Renders eigener Dokumentation entsprechen Replikate immer dem Instanztyp des Primärservers und werden entsprechend abgerechnet; für den Hochverfügbarkeits-Standby ist ein Pro- oder Accelerated-Instanztyp erforderlich, wobei dessen Aktivierung einen Neustart der Datenbank auslöst.

Wichtigste Funktionen:

• Git-basierte Bereitstellung mit Webdiensten, Workern, Cron-Jobs und verwalteten Datenbanken als vollwertige Typen
• Lese-Replikate für leseintensive Workloads, die über das Dashboard hinzugefügt werden
• Hochverfügbarkeits-Standby für berechtigte Instanztypen
• Unterstützung für SOC 2 Typ 2, ISO 27001, DSGVO und HIPAA (auf Wunsch)

Am besten geeignet für: Teams, die vor allem eine ausgefeiltere Version der Railway-Erfahrung wünschen und gerne ihre Datenbankkapazität selbst planen, anstatt sie automatisch skalieren zu lassen.

Vorteile:

• Vertrautes Full-Stack-Modell, das den Erwartungen eines Railway-Nutzers sehr nahekommt
• Die planbasierte Preisgestaltung lässt sich leicht kalkulieren
• Verwaltete Postgres- und Redis-Instanzen ohne separaten Anbieter

Nachteile:

• Die Skalierung der Datenbank erfolgt manuell: Man wählt einen Tarif aus und fügt bei Bedarf Replikate von Hand hinzu
• Die Aktivierung der Hochverfügbarkeit führt zu einem Neustart der Datenbank

Wie die Alternativen im Vergleich abschneiden

Die richtige Alternative wählen

Die zentrale Entscheidung ist, ob die Datenbank als Teil einer Full-Stack-Plattform skalieren soll oder als eigenständiger Dienst, bei dem die App anderweitig gehostet wird. Beide Wege sind machbar; der Unterschied liegt darin, wie viele Anbieter letztendlich im Stack landen und wer über das Hosting der App entscheidet.

Upsun ist die Option, bei der alles – Apps, Worker und Lese-Replikate der Datenbank – in einem einzigen Auto-Scaling-Modell und auf einer einzigen Rechnung zusammengefasst ist. Das ist besonders wichtig für Teams, die keinen separaten Datenbankanbieter einbinden wollen, nur um die Skalierungslücke zu schließen. 

Neon, PlanetScale und CockroachDB Serverless konzentrieren sich jeweils intensiv auf eine bestimmte Datenbank-Engine und ein bestimmtes Skalierungsmodell: Postgres-Rechenelastizität, MySQL-Sharding bzw. verteiltes SQL – und bei allen wird davon ausgegangen, dass das Hosting der App anderweitig abgewickelt wird. 

Aurora Serverless v2 ist die richtige Wahl für Teams, die bereits auf AWS standardisiert sind und lieber RDS erweitern möchten, als einen neuen Anbieter hinzuzunehmen. Render ist es wert, ausdrücklich erwähnt zu werden: Es entspricht am ehesten den eigenen Erfahrungen von Railway, und der ehrliche Kompromiss besteht darin, dass sich die Datenbank nach dem vom Team gewählten Tarif skaliert und nicht von selbst.

Häufig gestellte Fragen (FAQs)

Skaliert Railway seine verwalteten Datenbanken automatisch?

Nicht automatisch. Die Anwendungscontainer von Railway skalieren vertikal von selbst bis zu den Grenzen des gewählten Tarifs, und eine horizontale Skalierung für Apps ist über die öffentliche API möglich, wenn ein Team einen eigenen Autoscaler entwickelt. Die verwalteten Postgres-, MySQL-, Redis- und MongoDB-Dienste skalieren anders: Die Größe der Festplattenvolumes wird manuell über das Dashboard angepasst, und vertikale Rechenleistungserweiterungen über die Standardgrenzen des Tarifs hinaus erfolgen im Rahmen einer Vereinbarung über fest zugesagte Ausgaben mit dem Railway-Team.

Welche Railway-Alternative skaliert Postgres automatisch?

Neon skaliert die Rechenleistung von Postgres automatisch innerhalb eines konfigurierbaren Bereichs pro Zweig, einschließlich einer Skalierung auf Null für inaktive Zweige. Upsun skaliert PostgreSQL- und MariaDB-Lese-Replikate automatisch als Teil derselben Funktion, die auch seine Apps und Worker skaliert, während die primäre Schreibinstanz weiterhin vertikal durch manuelle Konfiguration skaliert wird. AWS Aurora Serverless v2 skaliert die Rechenleistung automatisch innerhalb eines ACU-Bereichs für Teams, die bereits auf AWS arbeiten.

Skaliert Upsun die primäre Datenbankinstanz automatisch oder nur die Lesereplikate?

Nur die Lesereplikate – seit dem Update der Upsun-Autoskalierungsfunktion im Juli 2026. Die primäre Lese-Schreib-Instanz von PostgreSQL oder MariaDB wird weiterhin wie bisher durch manuelle Konfiguration vertikal skaliert. Leseintensive Workloads profitieren direkt von dem neuen Autoskalierungsverhalten.

Ist PlanetScale oder Neon die bessere Wahl für ein Team, das von Railway umsteigt?

Das hängt von der bereits verwendeten Datenbank-Engine ab. PlanetScale basiert auf Vitess und eignet sich am besten für MySQL-kompatible Workloads, bei denen irgendwann horizontales Sharding erwartet wird. Neon ist eine serverlose Postgres-Plattform und passt besser zu Teams, die bereits Postgres nutzen und eine automatische Skalierung der Rechenleistung wünschen, ohne ein MySQL-basiertes Sharding-Modell einzuführen.

Ist Aurora Serverless v2 eine gute Wahl für ein Team, das von Railway umsteigt?

Es eignet sich besonders gut für Teams, die bereits die AWS-Infrastruktur nutzen oder bereit sind, umfassender darauf umzusteigen. Aurora Serverless v2 skaliert die Rechenleistung innerhalb eines ACU-Bereichs automatisch und kann bei unterstützten Engine-Versionen bei Inaktivität auf 0 ACUs pausieren. Es ersetzt nicht das Anwendungshosting von Railway und bietet keine Multi-Cloud-Flexibilität, da es ausschließlich auf AWS läuft.

Kann ein Team ohne Neuprogrammierung von Railway auf diese Alternativen umsteigen?

In der Regel reicht eine Konfigurationsanpassung statt einer kompletten Neuprogrammierung aus, wobei der Arbeitsaufwand je nach Plattform variiert. Der Wechsel zu Render kommt einer 1:1-Migration nahe, da beide Git-basierte Full-Stack-Plattformen sind. Der Wechsel zu Upsun bedeutet, eine YAML-Konfigurationsdatei hinzuzufügen, die die Anwendung und ihre Dienste beschreibt. Der Wechsel zu einer reinen Datenbankplattform wie Neon, PlanetScale, CockroachDB Serverless oder Aurora Serverless v2 bedeutet, die Anwendung dort weiter zu hosten, wo sie bereits läuft (oder sie separat zu verschieben), und sie auf die neue Datenbank umzuleiten – was in der Regel eine Änderung der Verbindungszeichenfolge sowie etwaige Schema- oder Erweiterungsunterschiede erfordert, die die neue Engine mit sich bringt.