Sometimes someone has to check what is really in the database: whether an order arrived, how many customers use a feature, which value a setting holds. Clusterward’s SQL console answers that in the browser – read-only, without handing out a password, and with every query in the audit log.
The SQL console is a query window in the Clusterward cockpit for PostgreSQL and MySQL databases on Scaleway. It runs one statement per query, with its own read-only login and inside a read-only transaction, and shows at most 1,000 rows within 60 seconds. A permission of its own decides who may use it; every query goes into the audit log.
The list shows only databases you could also open on their own page – with application, environment and service.
One statement, run with ⌘ / Ctrl + Enter. Time and rows are set right next to it.
Columns with their types, row count and duration. Copied as CSV with one click.
Text, database, row count and duration are in the audit log – with name and time.
Four layers make sure it only reads – each one is enough on its own.
A login of its own per database with the Read level. The console never uses the application’s login.
Every query runs in a transaction that may only read and is always rolled back. UPDATE, DELETE or CREATE end with an error.
No chained statements and no client commands such as \d or \!: the console talks to the database through a driver, not through a command-line client.
60 seconds and 1,000 rows per query, adjustable up to the ceiling your workspace sets.
Query text, database, row count and duration, with person and time. Result values are never stored.
A permission of its own, “Operations”. Anyone limited to applications sees only their databases and those of their customers.
On the instance page, ⋯ → “Query data” opens the console with the database already selected.
The result on the clipboard with one click, for a spreadsheet, a ticket or a follow-up question.
The database stays on the private network. No port-forward, no bastion, no open port.
The databases sit on the cluster’s private network and have no public endpoint.
The first query starts a small query runner in the cluster. After that it answers in a fraction of a second.
Clusterward reaches the runner through the Kubernetes API. Nothing is open outside the cluster.
PostgreSQL and MySQL are addressed through their drivers, results are read row by row.
The default applies per query. Your workspace sets the ceiling, up to the fixed maximum.
| What | Per query | Workspace ceiling |
|---|---|---|
| Run time | 60 seconds | 300 s, at most 600 s |
| Rows | 1,000 | 10,000, at most 50,000 |
| Statements | one | one |
| Length | up to 20,000 characters | fixed |
| Databases | PostgreSQL, MySQL | instances attached to a cluster |
The console queries the databases Clusterward creates for your services. How they come about, who may do what and what an auditor wants to see is described in Managed databases, Security & access and Audit & NIS2.
When read access to production data makes sense and how to build it without Clusterward is covered in the article Looking at production data without sharing the password.
PostgreSQL and MySQL per service, on the private network only.
Go to DatabasesRoles per area, mandatory 2FA and the audit log.
Go to SecurityEvidence from operations, checkable and exportable.
Go to Audit & NIS2Your question isn’t here? Write to us – we usually reply the same working day.
Ask a questionWe query a sample database, show the entry in the audit log and how a role limits access to the databases of one application.
