Verwaltete Datenbanken auf blitz.cloud - PostgreSQL, MariaDB, Redis

blitz.cloud bietet verwaltetes PostgreSQL 17, MariaDB 11.4 und Redis, bereitgestellt von Valkey 8. Eine Datenbank wird für dich angelegt, wenn eine App eine braucht, oder über die Seite Databases, und ihre Verbindungsdaten landen als Umgebungsvariablen in der App. Datenbanken sind nur aus deinen eigenen Apps erreichbar und werden jede Nacht gesichert.

Datenbank-Engines

Redis wird von Valkey bereitgestellt, dem Open-Source-Fork. Das Protokoll ist dasselbe, Redis-Clients und redis://-URLs funktionieren also unverändert.

MongoDB gibt es nicht. Seine Lizenz, die SSPL, soll genau die Art von Hosting-Angebot verhindern, die blitz.cloud wäre. Eine App, die MongoDB braucht, sagt das vor der Installation.

Unsicher, welche du nehmen sollst? PostgreSQL ist fast immer die richtige Antwort.

Eine Datenbank anlegen

Eine Datenbank entsteht auf einem von vier Wegen:

1. Du installierst eine App aus dem App Store, die eine braucht. Nextcloud bekommt zum Beispiel MariaDB.
2. Du rollst ein Docker-Image aus, und blitz.cloud erkennt, dass es eine braucht, oder du schaltest im Assistenten unter Advanced settings "Needs a database" (braucht eine Datenbank) ein.
3. Auf der Seite einer App öffnet "Give it a database" (gib ihr eine Datenbank) dasselbe Formular, mit dieser App schon ausgewählt.
4. Du legst auf der Seite Databases eine an, indem du Engine und Namen wählst, und verbindest sie dann mit einer App.

Eine neue Datenbank ist meist in unter einer Minute bereit. Als bereit gilt sie erst, wenn der Datenbankserver wirklich antwortet. Die Karte zeigt die Engine, wie viele Daten sie enthält und welche App sie nutzt. Die Verbindungsdaten stehen in eigenen Zeilen, jede mit einem Copy-Knopf: Connection-String, Host, Port, Datenbankname, Benutzer und Passwort. Passwort und Connection-String bleiben verborgen, bis du auf Show klickst.

Wie die App die Verbindungsdaten bekommt

Wenn die Variablennamen einer App bekannt sind, füllt blitz.cloud sie aus. Nextcloud bekommt zum Beispiel MYSQL_HOST, MYSQL_DATABASE, MYSQL_USER und MYSQL_PASSWORD. Der Assistent listet sie auf, bevor er irgendetwas anwendet.

Verbindest du eine Datenbank mit einer App, hat die App danach immer eine DATABASE_URL mit dem vollständigen Connection-String, und die Seite sagt, welche Einstellungen ausgefüllt wurden. Viele Tools lesen diesen Namen per Konvention, darunter Rails, Prisma-Schemas und Django mit dj-database-url.

Der Host im Connection-String ist ein kurzer interner Name. Er wird innerhalb deines Kontos aufgelöst und nirgendwo sonst.

Eine Datenbank pro App

Jede Datenbank gehört zu einer App, und jede App hat höchstens eine Datenbank. Zwei Apps auf einer Datenbank würden gegenseitig ihre Tabellen überschreiben; zwei WordPress-Seiten auf einer Datenbank zerstören sich gegenseitig die Beiträge. Die Datenbank ist nach der App benannt und wird mit ihr umbenannt.

Caches, die mit Store-Apps kommen

Manche Apps aus dem App Store bringen neben ihrer Datenbank einen kleinen Cache mit, etwa Paperless-ngx und Docmost. Das ist Valkey wie beim Redis oben, gehört aber zur App. Er schläft und wacht mit der App, wird mit ihr gelöscht, behält nichts und hat kein Backup. Er zählt nicht als eine der Datenbanken deines Tarifs, seine 48 MB Arbeitsspeicher zählen aber mit. Der Store zeigt den Cache vor der Installation an.

Schlafen mit deinen Apps

Eine Datenbank, die Daten hält, schläft, sobald jede App, die mit ihr verbunden ist, schläft oder pausiert ist, und startet wieder, bevor die App das tut. Die Seite der Datenbank zeigt währenddessen "Schläft" an. Eine Datenbank ohne verbundene App läuft weiter durch. Nach einem vollen Tag im Schlaf wird auch die Festplatte deines Kontos weggelegt, sodass das erste Aufwachen danach eine Minute oder zwei länger dauert, genau wie bei einer App, die ihre eigenen Dateien behält. Während eine Datenbank schläft, ändert sich nichts, und außer deinen eigenen Apps könnte sie ohnehin niemand erreichen.

Netzwerkzugriff

Datenbanken haben keine öffentliche Adresse und keinen offenen Port im Internet. Nur Apps in deinem eigenen Konto können sich verbinden. Das heißt auch: Von deinem Laptop aus mit psql oder einem grafischen Client kommst du heute nicht dran.

Löschen

Eine Datenbank, die eine App nutzt, lässt sich nicht einzeln löschen. Sie geht mit der App. Wenn du die App löschst, fragt blitz.cloud nach dem Eintippen ihres Namens, was mit der Datenbank passieren soll: für eine andere App behalten oder zusammen mit jeder nächtlichen Kopie löschen. Eine Standardantwort gibt es nicht.

Backups

Jede laufende Datenbank wird jede Nacht außerhalb unserer Server kopiert: Im kostenlosen Tarif bleiben 7 Nächte erhalten, mit Pro 30. Eine PostgreSQL- oder MariaDB-Datenbank auf eine Nacht zurückzusetzen ist ein Knopf, und das lässt sich rückgängig machen: Bevor etwas ersetzt wird, kopieren wir die Datenbank, wie sie gerade ist, und Undo spielt diese Kopie zurück. Details unter Backups.

Eine schlafende Datenbank wird nicht jede Nacht kopiert, weil sich ihre Daten im Schlaf nicht ändern können. Ihre letzte Kopie wurde gemacht, kurz bevor sie eingeschlafen ist.

"Download my data" in den Einstellungen enthält nicht, was in deinen Datenbanken steht. Die Daten selbst nimmst du mit Kopie herunterladen mit.

Daten mitbringen

Du ziehst von einem anderen Anbieter um? Du kannst einen PostgreSQL- oder MariaDB-Dump in eine leere Datenbank hochladen.

1. PostgreSQL: Mach einen Dump mit pg_dump -Fc --no-owner -d "<alte Verbindungs-URL>" -f app.dump (pg_dump 17 oder älter). MySQL oder MariaDB: Mach einen Dump mit mysqldump --single-transaction --routines --triggers <Datenbank> > app.sql (oder mariadb-dump) und packe ihn mit gzip, wenn du willst.
2. Öffne auf Databases bei der Datenbank Dump hochladen.
3. Zieh die Datei auf das Feld oder wähl sie auf deinem Rechner aus.

Die Datei geht von deinem Browser direkt in unseren Speicher, und das Feld zeigt, wie weit sie ist. Lass die Seite offen, bis dort steht, dass der Import läuft. Danach prüfen wir, dass die Datenbank keine Tabellen hat, und importieren die Datei in einem Zug. Wenn etwas schiefgeht, bleibt nichts übernommen. Owner, Rechte und Subscriptions im Dump werden weggelassen, und wir löschen die Datei, sobald der Import fertig ist. Bei MySQL oder MariaDB lassen wir USE- und CREATE-DATABASE-Zeilen und DEFINER-Klauseln weg, damit die Daten in dieser Datenbank landen; MariaDB kann nicht in einem Zug importieren, darum entfernen wir bei einem Fehler die Tabellen, die der Import schon angelegt hatte.

Diese Dateien gehen: das Custom-Format von pg_dump (.dump), tar, reines .sql und .sql.gz für PostgreSQL; ein .sql oder .sql.gz von mysqldump oder mariadb-dump für MariaDB. Grenzen: PostgreSQL und MariaDB, nur eine leere Datenbank, und eine Datei bis zum Speicher der Datenbank (heute 1 GB), nie mehr als 2 GB.

Kopie herunterladen

Öffne bei einer Datenbank Kopie herunterladen und drück Kopie machen. Das dauert ein paar Minuten. Sobald sie fertig ist, startet der Download von selbst, und das Feld behält 24 Stunden lang einen Knopf zum Herunterladen. Danach löschen wir die Kopie, und du kannst eine neue machen. Pro Datenbank gehen 10 Kopien am Tag.

Was du bekommst, hängt von der Datenbank ab:

• PostgreSQL: eine .dump-Datei im Custom-Format von pg_dump. Spiel sie mit pg_restore --no-owner -d "<Verbindungs-URL>" app.dump zurück oder lad sie hier in eine leere Datenbank hoch.
• MariaDB: eine .sql.gz-Datei. Lies sie mit gunzip -c app.sql.gz | mariadb -h <host> -u <user> -p <datenbank> ein.
• Redis: eine .rdb-Datei, die Redis und Valkey beim Start lesen.

Limits

Der kostenlose Tarif enthält eine Datenbank, Pro fünf. Jede Datenbank reserviert 1 GB Speicher (Redis: 0,5 GB) und etwas Arbeitsspeicher aus deinem Kontingent: 128 MB für PostgreSQL, 192 MB für MariaDB, 64 MB für Redis. Siehe Limits.

Die Datenbank-Versionen sind auf die oben genannten festgelegt. Automatische Upgrades auf eine neue Hauptversion gibt es nicht.