Datenbank-Addon oder Datenbankserver: der Unterschied, der wirklich zählt
Standardmäßig läuft die Datenbank einer neuen App als Addon auf dem Server der App selbst – günstig, schnell und genau richtig für den Einstieg. Was man verstehen sollte, bevor es in Produktion relevant wird: Geht dieser Server verloren, hat das Addon nur noch deine Backups als Rückfallebene. Ein Datenbankserver ist die andere Option – einer deiner eigenen Server, der nur Daten hält und sonst nichts, mit einer deutlich anderen Ausfall-Geschichte.
Was ein Datenbankserver tatsächlich ändert
Daten auf einen Datenbankserver zu verschieben ist nicht nur eine größere Box. Es ändert, was die Daten schützt:
- Er bekommt keinen Web-Proxy und keine Build-Tools, und es wird nie eine App auf ihn deployed – er existiert für genau eine Aufgabe.
- Seine Datastore-Ports sind nur für die App-Server offen, die ihn nutzen, nicht allgemein erreichbar.
- Backups, verifiziert. Jede App-Datenbank auf einem Datenbankserver bekommt ein tägliches Backup, und jedes davon wird durch tatsächliches Wiederherstellen geprüft – nicht einfach als gut angenommen, weil der Job Erfolg gemeldet hat.
- Ein Standby, bei Pro und Team. Also create a standby provisioniert einen zweiten Datenbankserver derselben Größe, der eine Live-Kopie von Postgres, MySQL und Redis hält, alle 5 Minuten geprüft.
- Automatisches Failover. Antwortet der Primärserver 3 Minuten lang nicht und hat der Standby unabhängig davon ebenfalls den Kontakt verloren, übernimmt der Standby auf den üblichen Ports, jede App, die ihn nutzt, deployed gegen ihn neu, und du bekommst eine Benachrichtigung mit genauer Auflistung, was umgezogen ist.
Ein Addon auf dem App-Server hat davon konstruktionsbedingt nichts – es war nie als Durability-Schicht gedacht, nur als bequemer Standard.
Eine bestehende App umziehen
Settings → Resources → Move data to a database server auf der App listet genau auf, was kopiert wird und was leer startet, bevor du den Button drückst:
- Die App stoppt.
- Postgres und MySQL werden gedumpt und auf dem Datenbankserver wiederhergestellt.
- Redis, MongoDB, Object Storage, RabbitMQ-Definitionen und ClickHouse werden ebenfalls kopiert – ein nur von dieser App genutztes Elasticsearch kommt auch mit.
- Die App deployed neu.
Schlägt ein Schritt fehl, geht die App zurück zu ihren alten Daten – read-only, nie überschrieben –, sodass ein fehlgeschlagener Umzug nicht genau das riskiert, was er schützen sollte.
Wann der Standard trotzdem die richtige Wahl ist
Nicht jede App braucht das am ersten Tag. Ein risikoarmes internes Tool, eine Staging-Umgebung, alles, wo der Verlust eines Tages an Daten durch eine Backup-Wiederherstellung ein Schulterzucken statt eines Vorfalls ist – dafür ist der Addon-Standard korrekt dimensioniert, und der Umzug ist nur eine Settings-Seite entfernt, sobald sich die Rechnung ändert. Der Punkt ist nicht “immer einen Datenbankserver benutzen”. Es geht darum, zu wissen, welchen du tatsächlich betreibst, bevor ein Ausfall der Moment ist, in dem du es herausfindest.
Vollständige Referenz, inklusive Connection Pooling und Postgres-Upgrades: Datenbankserver.