Manchmal muss jemand nachsehen, was wirklich in der Datenbank steht: ob eine Bestellung angekommen ist, wie viele Kunden eine Funktion nutzen, welcher Wert in einer Einstellung liegt. Die SQL-Konsole von Clusterward beantwortet das im Browser – nur lesend, ohne ein Passwort weiterzugeben und mit jeder Abfrage im Audit-Log.
Die SQL-Konsole ist ein Abfragefenster im Clusterward-Cockpit für PostgreSQL- und MySQL-Datenbanken auf Scaleway. Sie führt eine Anweisung pro Abfrage aus, mit einem eigenen Lese-Login und in einer Nur-Lese-Transaktion, und zeigt höchstens 1.000 Zeilen in 60 Sekunden. Wer sie nutzen darf, regelt eine eigene Berechtigung; jede Abfrage landet im Audit-Log.
Die Liste zeigt nur Datenbanken, die Sie auch auf ihrer Seite öffnen dürften – mit Anwendung, Umgebung und Service.
Eine Anweisung, ausgeführt mit ⌘ / Strg + Enter. Zeit und Zeilen stellen Sie daneben ein.
Spalten mit ihren Typen, Zeilenzahl und Dauer. Mit einem Klick als CSV kopiert.
Text, Datenbank, Zeilenzahl und Dauer stehen im Audit-Log – mit Namen und Zeit.
Vier Schichten sorgen dafür, dass nur gelesen wird – jede davon reicht allein.
Pro Datenbank ein eigener Login mit der Stufe Lesen. Die Konsole nutzt nie den Login der Anwendung.
Jede Abfrage läuft in einer Transaktion, die nur lesen darf und immer zurückgerollt wird. UPDATE, DELETE oder CREATE enden mit einem Fehler.
Keine Befehlsketten und keine Client-Befehle wie \d oder \!: Die Konsole spricht über einen Treiber mit der Datenbank, nicht über ein Kommandozeilenprogramm.
60 Sekunden und 1.000 Zeilen pro Abfrage, anpassbar bis zur Grenze, die Ihr Workspace setzt.
Abfragetext, Datenbank, Zeilenzahl und Dauer, mit Person und Zeit. Ergebniswerte werden nie gespeichert.
Eine eigene Berechtigung „Operations“. Wer auf Anwendungen begrenzt ist, sieht nur deren Datenbanken und die ihrer Kunden.
Auf der Instanzseite öffnet ⋯ → „Daten abfragen“ die Konsole mit der Datenbank vorausgewählt.
Das Ergebnis mit einem Klick in der Zwischenablage, für Tabelle, Ticket oder Rückfrage.
Die Datenbank bleibt im privaten Netz. Kein Port-Forward, keine Bastion, kein offener Port.
Die Datenbanken liegen im Private Network des Clusters und haben keinen öffentlichen Endpunkt.
Die erste Abfrage startet einen kleinen Query-Runner im Cluster. Danach antwortet er in Bruchteilen einer Sekunde.
Clusterward erreicht den Runner über die Kubernetes-API. Außerhalb des Clusters ist nichts offen.
PostgreSQL und MySQL werden über ihre Treiber angesprochen, Ergebnisse zeilenweise gelesen.
Die Voreinstellung gilt pro Abfrage. Die Grenze legt Ihr Workspace fest, bis zur festen Obergrenze.
| Was | Pro Abfrage | Workspace-Grenze |
|---|---|---|
| Laufzeit | 60 Sekunden | 300 s, höchstens 600 s |
| Zeilen | 1.000 | 10.000, höchstens 50.000 |
| Anweisungen | eine | eine |
| Länge | bis 20.000 Zeichen | fest |
| Datenbanken | PostgreSQL, MySQL | Instanzen an einem Cluster |
Die Konsole fragt die Datenbanken ab, die Clusterward für Ihre Services anlegt. Wie diese entstehen, wer was darf und was ein Prüfer sehen will, beschreiben Managed Datenbanken, Sicherheit & Zugriff und Audit & NIS2.
Wann ein Lesezugriff auf Produktionsdaten sinnvoll ist und wie man ihn ohne Clusterward baut, zeigt der Beitrag Produktionsdaten ansehen, ohne das Passwort zu teilen.
PostgreSQL und MySQL pro Service, nur im privaten Netz.
Zu DatenbankenRollen pro Bereich, Pflicht-2FA und das Audit-Log.
Zu SicherheitNachweise aus dem Betrieb, prüfbar und exportierbar.
Zu Audit & NIS2Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir fragen eine Beispieldatenbank ab, zeigen den Eintrag im Audit-Log und wie eine Rolle den Zugriff auf die Datenbanken einer Anwendung begrenzt.
