Can the SQL console change data?

Only if you allow it. Queries run with a login of their own with read rights, in a read-only transaction that is rolled back afterwards – each of these layers prevents writes on its own. Changes take a separate path: a switch allows them for the workspace, then every tab shows “Allow changes”. Each change runs as a preview first, which is rolled back and says how many rows it would change; “Apply changes” runs exactly that statement. DROP, TRUNCATE and UPDATE or DELETE without WHERE ask for the database name. Databases, roles and privileges can never be changed through the console.

Which databases can I query?

PostgreSQL and MySQL databases on Scaleway whose instance is attached to a cluster – that is, all those Clusterward created with a cluster. You only see databases you could also open on their own page.

Who may use the SQL console?

Anyone with the “Operations” permission: View shows the page, Operate runs queries, Manage changes the workspace ceilings. On top, at least View on Databases is needed. Existing roles start without it, and API tokens cannot use the console. Applying changes needs Manage on “Operations” and Operate on Databases – and only while the workspace allows changes. AI assistants cannot reach the console either.

What goes into the audit log?

The query text, the database, the number of rows and the duration, plus who asked and when. Result values are never stored – the audit log must not become a second copy of your customer data. Parameter values are part of the entry, except for names that look like a secret. After 12 months Clusterward deletes the entry automatically, like every audit entry. Every preview and every applied change is in it too, with the statement and the number of rows changed.

What if a change was wrong?

The console cannot undo an applied change. That is why the preview shows beforehand how many rows are affected, and big changes ask for the database name. Before a larger change, take a backup on the instance page under Backups; a restore lands in a new database and leaves the running one alone.

Can I download results?

Yes, as CSV, as CSV for Excel (semicolon-separated, special characters intact) or as JSON – with the columns in the order you currently see. The file is built in your browser. The audit log holds the query, never its result. Values starting with =, +, - or @ get a leading apostrophe so Excel does not run them as a formula.

Can I save queries and share them with my team?

Yes. A saved query is private or visible to the whole workspace. Parameters such as :customer are filled in when you run it; the values reach the database as bound parameters, never inside the text. A link opens a query in a new tab without running it – so every run stays a deliberate one.

What if a query runs too long?

Cancel stops exactly your statement in the database. Why it was slow is shown by the query plan: EXPLAIN as a tree with the most expensive step marked, on PostgreSQL optionally with real rows and times. The diagnostics also show long-running statements, blocking and unused indexes of the database.

Do I have to install anything in the cluster?

No. The first query starts a small query runner in the cluster; that takes up to a minute because it loads its database drivers at start and needs outbound access to the npm registry for that. Clusters whose operator identity predates the console renew it once in the cockpit. Under Infrastructure → SQL console you see per cluster whether the runner is running and how much CPU and memory it uses and reserves; “Remove runner…” frees its reservation until the next query.

What happens to the read-only login when the database is deleted?

It lives and dies with its database. When the database is deleted or its customer is offboarded, the console’s login goes with it.

SQL console

SQL console for production databases: read, and change only with a preview

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. When a value really has to be corrected, allow changes: they run as a preview first and then exactly as previewed.

Book a demo Managed databases

The SQL console in the Clusterward cockpit: database selected, query and result (simplified illustration) — Illustration: a simplified view. The product shows more details and options.

In short

What the SQL console is

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. It comes with an editor with completion, a schema browser, saved queries with parameters, ready-made diagnostics and the query plan. Changes are a separate, deliberate step: off until your workspace allows them, and each one runs as a preview first.

At a glance

Databases: PostgreSQL and MySQL on Scaleway, on the private network
Access: Its own read-only login per database, read-only transaction
Changes: Off until the workspace allows them; preview first, then apply
Limits: 60 seconds and 1,000 rows per query, adjustable
Tools: Editor, schema, tabs, saved queries, diagnostics, EXPLAIN
Evidence: Every query in the audit log for 12 months, never a result value
Permissions: A permission of its own, scoped to applications
Setup: None – the runner starts with the first query

How it works

From question to answer

01
Pick a database
The list shows only databases you could also open on their own page – with application, environment and service.
02
Write the query
In an editor that completes tables and columns. ⌘ / Ctrl + Enter runs the statement – or only the selected one. Time and rows are set right next to it.
03
Read the result
Columns with their types, row count and duration – full screen, sortable, as CSV, Excel or JSON.
04
Evidence
Text, database, row count and duration are in the audit log – with name and time.

What’s included

What the SQL console covers

When you query, two layers prevent writes, each on its own; the others limit what a query can do beyond that.

Its own read-only login

A login of its own per database with the Read level. The console never uses the application’s login.

Read-only transaction

Every query runs in a transaction that may only read and is always rolled back. UPDATE, DELETE or CREATE end with an error – changes take a separate path with a preview.

One statement

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.

Time and row limits

60 seconds and 1,000 rows per query, adjustable up to the ceiling your workspace sets.

Audit log

Query text, database, row count and duration, with person and time. Result values are never stored. Entries are deleted automatically after 12 months.

Permissions per application

A permission of its own, “Operations”. Anyone limited to applications sees only their databases and those of their customers.

Straight from the database

On the instance page, ⋯ → “Query data” opens the console with the database already selected.

CSV, Excel or JSON

The result on the clipboard or as a file – with exactly the columns and the order you see. The file is built in the browser.

No tunnel

The database stays on the private network. No port-forward, no bastion, no open port.

For real work

More than a query window

What you need to answer a question to the database quickly and traceably.

Editor with completion

Highlighting for PostgreSQL or MySQL, tables and columns to pick from, ⌘ / Ctrl + Enter for the selection and one click that formats the query.

Schema browser

Tables, columns with their types and the indexes of the chosen database, read with the console’s read-only login.

Several tabs

Up to ten queries side by side. Text and database stay in your browser, results are never stored.

Full-screen results

Open long values and JSON in a cell, read a row as a record, sort, hide and widen columns, load more rows.

Saved queries

For yourself or the whole team. :name parameters are filled in when you run them; the values reach the database as bound parameters, never inside the query text.

History and links

Reopen earlier queries from your own history, which reaches back 12 months. A link opens a query in a new tab without running it.

Ready-made diagnostics

Size, largest tables and indexes, unused indexes, dead rows, sessions, long-running statements, blocking and connections – each diagnostic says what the read-only login cannot see.

Cancel a running query

Cancel stops exactly your statement in the database – through a second connection with the same read-only login, without touching other sessions.

Query plan as a tree

EXPLAIN draws the plan and marks the most expensive step. On PostgreSQL, EXPLAIN ANALYZE adds real rows and times.

Changes

Changing data – the preview first, then the change

For when a value has to be corrected or a row added. Off until your workspace allows it.

01
Allow changes
Someone who may manage “Operations” switches changes on for the workspace. Then each tab shows “Allow changes” – for everyone who may also operate databases.
02
Preview
The statement runs inside a transaction that is rolled back and says what it would do: “UPDATE would change 37 rows”, with the rows a RETURNING clause names. Nothing is saved yet.
03
Apply
“Apply changes” runs exactly the previewed statement with the same values. DROP, TRUNCATE and UPDATE or DELETE without WHERE ask for the database name first.
04
Record
Preview and apply are in the audit log: statement, rows changed, person and time.

Changes run with the database’s own login, because only it may change the structure of its tables; the console’s read login is never raised for it. Not available: databases, roles and privileges, extensions, COPY and session commands – Clusterward manages users and levels on the instance page. MySQL structure changes cannot be checked in advance, because MySQL commits them at once; the console says so and asks for the database name. The console cannot undo a change – before a big one, take a backup on the instance page.

Standards, not home-made

How the query reaches the database

Private network
The databases sit on the cluster’s private network and have no public endpoint.
Runner in the cluster
The first query starts a small query runner in the cluster. After that it answers in a fraction of a second; the console shows whether it runs and how much CPU and memory it uses.
Through the Kubernetes API
Clusterward reaches the runner through the Kubernetes API. Nothing is open outside the cluster.
Driver, not command line
PostgreSQL and MySQL are addressed through their drivers, results are read row by row.

What changes

Database access with and without Clusterward

Facts

Defaults and ceilings

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
Load more	more rows per click	up to the row ceiling
Open tabs	up to 10	fixed
Databases	PostgreSQL, MySQL	instances attached to a cluster
Changes	off; preview first, then apply	switch per workspace

The SQL console in context

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.

Related pages

What goes with it

Managed databases

PostgreSQL and MySQL per service, on the private network only.

Go to Databases

Security & access

Roles per area, mandatory 2FA and the audit log.

Go to Security

Audit & NIS2

Evidence from operations, checkable and exportable.

Go to Audit & NIS2

FAQ

Frequently asked questions about the SQL console

Only if you allow it. Queries run with a login of their own with read rights, in a read-only transaction that is rolled back afterwards – each of these layers prevents writes on its own. Changes take a separate path: a switch allows them for the workspace, then every tab shows “Allow changes”. Each change runs as a preview first, which is rolled back and says how many rows it would change; “Apply changes” runs exactly that statement. DROP, TRUNCATE and UPDATE or DELETE without WHERE ask for the database name. Databases, roles and privileges can never be changed through the console.
Anyone with the “Operations” permission: View shows the page, Operate runs queries, Manage changes the workspace ceilings. On top, at least View on Databases is needed. Existing roles start without it, and API tokens cannot use the console. Applying changes needs Manage on “Operations” and Operate on Databases – and only while the workspace allows changes. AI assistants cannot reach the console either.
The query text, the database, the number of rows and the duration, plus who asked and when. Result values are never stored – the audit log must not become a second copy of your customer data. Parameter values are part of the entry, except for names that look like a secret. After 12 months Clusterward deletes the entry automatically, like every audit entry. Every preview and every applied change is in it too, with the statement and the number of rows changed.
No. The first query starts a small query runner in the cluster; that takes up to a minute because it loads its database drivers at start and needs outbound access to the npm registry for that. Clusters whose operator identity predates the console renew it once in the cockpit. Under Infrastructure → SQL console you see per cluster whether the runner is running and how much CPU and memory it uses and reserves; “Remove runner…” frees its reservation until the next query.

Your question isn’t here? Write to us – we usually reply the same working day.

Ask a question

The SQL console in the demo

We query a sample database, show the entry in the audit log and how a role limits access to the databases of one application.

Book a demo