Die besten Alternativen zur DigitalOcean-App-Plattform für hohe Arbeitslasten im Jahr 2026

Die DigitalOcean App Platform ist eine verwaltete PaaS, die aus Git oder einem Container-Image bereitgestellt wird – mit automatischem HTTPS, Abrechnung über einen einzigen Anbieter und einem wirklich einfachen Weg vom Repo zum laufenden Dienst. Für kleine Teams und Produkte in der Frühphase ist genau diese Einfachheit der Clou.

Die Lücke zeigt sich, sobald die Auslastung steigt. Die eigene Autoscaling-Funktion der App Platform wurde 2026 verbessert: Das anfragenbasierte Autoscaling, das auf Anfragen pro Sekunde und die P95-Latenz reagiert, wurde im Mai 2026 allgemein verfügbar und funktioniert nun sowohl bei Shared- als auch bei dedizierten CPU-Tarifen, nicht mehr nur bei dedizierten. Das CPU-basierte Autoscaling erfordert weiterhin einen dedizierten CPU-Tarif. Die Datenbankebene erhielt dieses Upgrade nicht. Die Managed Databases von DigitalOcean skalieren den Speicher automatisch, überwachen die Festplattenauslastung und erweitern die Kapazität im Hintergrund ohne Ausfallzeiten. 

Die Rechenleistung – also die CPU und der Arbeitsspeicher, auf denen ein Datenbankcluster läuft – skaliert überhaupt nicht automatisch: Eine Erhöhung bedeutet den Wechsel zu einem größeren Tarif, eine Änderung, die von einer Person oder einer Pipeline ausgelöst werden muss. Bei einer hohen, anhaltenden Auslastung kann die Anwendungsebene auf Echtzeit-Signale reagieren. Die Rechenebene der Datenbank kann das nicht; nur ihre Festplatte kann das.

Dieser Leitfaden behandelt die Plattformen, auf die Teams umsteigen, wenn es speziell diese Lücke zwischen Datenbank und Rechenleistung ist – und nicht die Anwendungsebene –, die die Entscheidung bestimmt.

Die wichtigsten Erkenntnisse

• Dieser Leitfaden vergleicht die DigitalOcean App Platform mit Plattformen, die ab 2026 eine echte Lösung für die Skalierung der Datenbank-Rechenleistung unter hoher Auslastung bieten – und nicht nur für das Speicherwachstum.
• Upsun eignet sich am besten für Teams, die möchten, dass sich Anwendungen, Worker und verwaltete PostgreSQL- oder MariaDB-Lese-Replikate jeweils unabhängig voneinander in Echtzeit und entsprechend ihrer eigenen CPU- und Speicherauslastung automatisch skalieren, ohne einen separaten Datenbankanbieter in den Stack aufnehmen zu müssen.
• Speziell entwickelte Datenbankplattformen lösen das Problem der Datenbankschicht gezielt: Neon für serverloses Postgres-Computing, 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 jedoch weiterhin separat gelöst werden.
• Render wird als die Full-Stack-Lösung aufgeführt, die der Erfahrung von DigitalOcean am nächsten kommt, wobei der Kompromiss klar benannt wird: Die Datenbank skaliert entsprechend dem von dir gewählten Tarif, nicht automatisch.

Worauf du bei einer auf automatische Skalierung ausgerichteten Alternative zur DigitalOcean App Platform achten solltest

• Autoskalierung der Datenbank-Rechenleistung versus reine Speicherskalierung. Ob sich CPU und Arbeitsspeicher einer Datenbank automatisch mit der Auslastung skalieren oder ob nur der Festplattenspeicher skaliert wird, während eine Erhöhung der Rechenleistung eine manuelle Tarifänderung erfordert.
• 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äre Instanz 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 sie auch Nicht-Produktionsumgebungen abdecken.

Warum die Datenbankebene von DigitalOcean unter hoher Last an ihre Grenzen stößt

In den Release-Notes von DigitalOcean wird die anfragenbasierte automatische Skalierung beschrieben, die seit Mai 2026 allgemein verfügbar ist und auf die Live-Anfragen pro Sekunde sowie die P95-Antwortlatenz sowohl bei App-Instanzen mit gemeinsam genutzter als auch bei dedizierter CPU reagiert. Die CPU-basierte automatische Skalierung ist weiterhin auf Tarife mit dedizierter CPU beschränkt. Das ist die App-Ebene und stellt eine echte Verbesserung gegenüber dem früheren „Alles-oder-nichts“-Modell der App-Plattform dar, bei dem nur dedizierte CPUs zur Verfügung standen.

Managed Databases haben kein vergleichbares Upgrade erhalten. Die automatische Skalierung des Speichers ist allgemein verfügbar und erfolgt automatisch: In der Dokumentation von DigitalOcean wird beschrieben, dass die Festplattenauslastung kontinuierlich überwacht wird und der Speicher im Hintergrund hochskaliert wird, sobald ein konfigurierter Schwellenwert überschritten wird – ohne Ausfallzeiten und ohne manuelle Schritte. Bei CPU und RAM sieht es anders aus. Die Größenanpassung der Rechenleistung bedeutet, über die Konsole oder die API eine neue Tarifgröße auszuwählen – eine Maßnahme, die ein Team bewusst ergreift; in der Dokumentation von DigitalOcean zur Größenanpassung wird dies als asynchroner Vorgang beschrieben, der bei den meisten Engines keine Ausfallzeiten verursacht, aber es ist eine Änderung, die jemand oder etwas initiieren muss. Bei einer hohen, anhaltenden Auslastung hält die Festplatte von selbst mit. Die Rechenleistung, die die Abfragen bedient, tut dies jedoch nicht, bis eine Person oder eine Pipeline die Größe anpasst.

Upsun, auf das weiter unten eingegangen wird, ist die Alternative, die entwickelt wurde, um genau diese Lücke zu schließen: Anwendungen, Hintergrundprozesse sowie PostgreSQL- oder MariaDB-Lese-Replikate skalieren sich jeweils unabhängig voneinander in Echtzeit automatisch, basierend auf ihrer eigenen CPU- und Speicherauslastung, ohne dass ein separater Datenbankanbieter in den Stack integriert werden muss.

Die besten Alternativen zur DigitalOcean App Platform für hohe Auslastungen 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. Die automatische Skalierung wendet dasselbe Modell auf drei Ebenen an, die jeweils unabhängig voneinander in Echtzeit überwacht und skaliert werden: Anwendungen (seit der ursprünglichen Einführung der Funktion in der Produktivumgebung), Hintergrundprozesse (seit März 2026) und ab Juli 2026 PostgreSQL- und MariaDB-Lese-Replikate.

 Jede Ebene überwacht ihre eigene CPU- und Speicherauslastung anhand von Schwellenwerten, die ein Team konfiguriert, und fügt entsprechend Kapazität hinzu oder entfernt sie. So kann ein Anstieg des Leseverkehrs die automatische Skalierung der Replikate auslösen, ohne die Kapazität der App oder der Worker zu beeinträchtigen – und umgekehrt gilt das Gleiche. 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 Ticket zur manuellen Größenanpassung mehr benötigt, um mit leseintensiver Last Schritt zu halten.

Wichtigste Funktionen:

• Unabhängige, in Echtzeit erfolgende automatische Skalierung für Anwendungen, Worker und PostgreSQL- oder MariaDB-Lese-Replikate, jeweils mit eigenen, pro Umgebung konfigurierten CPU- und Speicher-Schwellenwerten.
• 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, bemessen 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 kompletten Anwendungsstack unter hoher oder schwankender Auslastung betreiben und möchten, dass sich der leseintensive Datenbankverkehr 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 Skalierung der Datenbank 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 Zeit der Inaktivität auf null heruntergefahren. Da Speicher und Rechenleistung voneinander 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, produktionsähnliche Datenbankkopien.
• Rechenleistung für Lesereplikate, 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 hoher, schwankender 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 immer noch einen Ort, an dem es seine App ausführen kann, und die Skalierung dieser App ist ein separates Problem, das gelöst werden muss.
• 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 Festplattenskalierung, wobei Vitess das horizontale Sharding auf der Speicherebene übernimmt. Die automatische Festplattenskalierung 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 Festplattenskalierung, 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 unter hohem Schreibaufkommen betreiben, davon ausgehen, dass ein einzelner Primärserver irgendwann nicht mehr ausreicht, und 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.
• Wie Neon ist es eher ein Datenbankdienst als ein Anwendungshost, daher ist die automatische Skalierung auf Anwendungsebene nicht Teil des Angebots.

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 im Produkt integriert und erfordert keinen separaten Konfigurationsschritt.

Wichtigste Funktionen:

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

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

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 keine Anwendungsschicht, sodass sie die Skalierung der Datenbank isoliert löst, anstatt sie mit der Skalierung von App und Workern zu verknüpfen.

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.

Wichtigste Funktionen:

• Automatische Skalierung der Rechenleistung innerhalb eines konfigurierbaren ACU-Bereichs.
• Automatische Pause auf 0 ACUs bei unterstützten Aurora PostgreSQL- und Aurora MySQL-Versionen.
• Enge Integration mit dem restlichen 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 der Rechenleistung für 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 Cluster, die nur zeitweise genutzt werden.
• 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 nach wie vor eine manuelle, kurzzeitig störende Änderung der Instanzklasse.
• Aurora Serverless v2 skaliert die Datenbank; die Anwendungsberechnungen auf AWS sind ein separater Dienst (App Runner, ECS oder ähnliches) mit eigener Skalierungskonfiguration.

Render

Die Full-Stack-Lösung, die der Entwicklererfahrung der DigitalOcean App Platform 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 des 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 der Dokumentation von Render entsprechen Replikate immer dem Instanztyp der Primärinstanz und werden entsprechend abgerechnet; für den Hochverfügbarkeits-Standby-Modus ist ein Instanztyp vom Typ „Pro“ oder „Accelerated“ erforderlich, wobei die Aktivierung einen Neustart der Datenbank zur Folge hat.

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 auf berechtigten Instanztypen.
• SOC 2 Typ 2, ISO 27001, DSGVO und opt-in-basierte HIPAA-Unterstützung.

Am besten geeignet für: Teams, die vor allem eine ausgefeiltere Erfahrung mit einem einzigen Anbieter suchen, die der von DigitalOcean selbst nahekommt, und die es vorziehen, die Datenbankkapazität selbst zu planen, anstatt sie automatisch skalieren zu lassen.

Vorteile:

• Vertrautes Full-Stack-Modell, das dem entspricht, was ein Nutzer der DigitalOcean App Platform bereits erwartet.
• 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.
• Das Aktivieren der Hochverfügbarkeit führt zu einem Neustart der Datenbank.
• Die Skalierung auf App-Ebene und die Skalierung auf Datenbankebene basieren nicht auf demselben Autoscaling-Modell; ein Team plant die Datenbankkapazität unabhängig davon, wie sich seine Webdienste und Worker skalieren.

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, wobei die App an anderer Stelle 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 zusammengefasst ist, wobei jede Ebene auf ihre eigene CPU- und Speicherauslastung in Echtzeit reagiert, und das alles auf einer einzigen Rechnung. Das ist besonders wichtig für Teams, die keinen separaten Datenbankanbieter einbinden wollen, nur um die Lücke bei der Rechenleistung zu schließen, die DigitalOceans eigene Managed Databases hinterlassen. Neon, PlanetScale und CockroachDB Serverless konzentrieren sich jeweils intensiv auf eine bestimmte Datenbank-Engine und ein bestimmtes Skalierungsmodell: Rechenelastizität bei Postgres, Sharding bei MySQL und verteiltes SQL – und bei allen wird davon ausgegangen, dass das App-Hosting 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 kommt der Erfahrung mit DigitalOcean am nächsten, 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 

Skaliert die verwaltete Datenbank der DigitalOcean App Platform bei hoher Auslastung automatisch?

Teilweise. Der Speicher skaliert automatisch: Die Managed Databases von DigitalOcean überwachen die Festplattenauslastung und fügen im Hintergrund ohne Ausfallzeiten Kapazität hinzu, sobald ein konfigurierter Schwellenwert überschritten wird. Die Rechenleistung – also die CPU und der Arbeitsspeicher, auf denen ein Datenbankcluster läuft – skaliert nicht automatisch. Eine Erhöhung bedeutet, über die Konsole oder die API auf einen größeren Tarif umzusteigen – eine Änderung, die ein Team selbst auslösen muss.

Skaliert die DigitalOcean App Platform Anwendungen automatisch?

Ja, allerdings mit einer Einschränkung hinsichtlich der verwendeten Metrik. Die anfragenbasierte automatische Skalierung, die auf Anfragen pro Sekunde und die P95-Latenz reagiert, ist seit Mai 2026 allgemein verfügbar und funktioniert sowohl bei gemeinsam genutzten als auch bei dedizierten CPU-Tarifen. Die CPU-basierte automatische Skalierung ist weiterhin auf dedizierte CPU-Tarife beschränkt.

Welche Alternative zur DigitalOcean App Platform skaliert die Datenbank-Rechenleistung automatisch?

Neon skaliert die Rechenleistung von Postgres innerhalb eines konfigurierbaren Bereichs pro Zweig automatisch, einschließlich einer Skalierung auf Null für inaktive Zweige. Upsun skaliert PostgreSQL- und MariaDB-Lese-Replikate 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 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 unter hoher Auslastung profitieren direkt von dem neuen Autoskalierungsverhalten.

Ist PlanetScale oder Neon die bessere Wahl für ein Team, das von der DigitalOcean App Platform wechselt?

Das hängt von der bereits verwendeten Datenbank-Engine ab. PlanetScale basiert auf Vitess und eignet sich am besten für MySQL-kompatible Workloads mit hohem Schreibaufkommen, bei denen langfristig 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.

Kann ein Team ohne Neuprogrammierung von der DigitalOcean App Platform auf diese Alternativen migrieren?

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 mit integriertem, verwaltetem Postgres 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 die Berücksichtigung etwaiger Schema- oder Erweiterungsunterschiede erfordert, die die neue Engine mit sich bringt.