Everyone has felt it: the support ticket says one customer's row has bad data, and the fix is a hand-written UPDATE against production. You read the WHERE clause five times. You add a LIMIT even though UPDATE does not take one. You ask a colleague to look over your shoulder.
SQL Studio — the data studio built into every DanubeData managed PostgreSQL database — was designed around exactly that moment. Here is the workflow, end to end.
Step 1: Find the row (you cannot break anything yet)
Open your instance and click SQL Studio. Studio always starts in read-only mode — browse anything, change nothing. Pick the table in the sidebar and narrow down with per-column filters (email = ..., status ILIKE 'pend%', deleted_at IS NULL) instead of writing a query. Click a column header to sort.
Step 2: Flip on write mode — deliberately
Editing is behind an explicit Write mode toggle in the top bar. This is by design: nobody edits production because their cursor slipped.
Step 3: Stage your changes
Now the grid becomes an editor, but nothing you do here touches the database yet:
- Double-click a cell to change its value — the cell highlights as pending.
- Need a real
NULLor the column default? Use the explicit NULL / DEF buttons. The classic trap where an empty string silently becomes NULL (or the reverse) cannot happen here. - + Add row appends a new row inline; columns you leave untouched take their database defaults.
- The delete toggle marks rows for removal — they stay visible, struck through, until you commit.
The toolbar counts your pending changes as you go. Tables are matched by their full primary key — composite keys included — so an edit can only ever touch the row you see.
Step 4: Commit once, atomically — or walk away
Click Commit and every staged change is applied in a single database transaction. If any one of them fails — a constraint, a bad type, a foreign key — nothing is written, the error is shown, and your staged changes are kept so you can fix the problem and retry. Click Discard instead and the whole set evaporates without a trace.
One commit can carry up to 500 staged changes. If you navigate away with changes pending, Studio stops you and asks whether to commit or discard first.
The guardrails you do not see until you need them
- Destructive operations interrogate you. Truncating a table asks for confirmation; dropping one makes you type its exact name.
- Everything is on the record. Every write — grid commits, SQL statements, table operations — is recorded in the instance's query log with who, what and when. Your teammates can see exactly which fix was applied.
- Credentials stay home. Queries run through an isolated agent inside your own tenant environment; database credentials never reach the browser, let alone a laptop keychain.
- No-key tables are protected from themselves. A table without a primary key cannot be edited from the grid (there is no safe way to address a single row) — use the SQL editor for those.
Bulk fixes
For more rows than you want to touch by hand, two options stay inside the same safety model: the CSV import wizard (map columns, then insert in bulk) and the SQL editor — which runs read-only by default too, and asks before executing destructive statements once write mode is on.
Try the calm version of that ticket
Next time the fix-this-row ticket lands, skip the sweaty UPDATE. Filter, stage, review, commit — with the audit log writing itself.
👉 SQL Studio is included free with every managed PostgreSQL database. See the feature overview, read the docs, or deploy a database and open Studio from the instance page.
