QueryProxy vs CloudBeaver
CloudBeaver is the browser-based edition of DBeaver — a full database client for browsing schemas, editing data and running SQL. QueryProxy is not a client; it is the approval step in front of one.
Updated:
At a glance
| Aspect | QueryProxy | CloudBeaver |
|---|---|---|
| What it is | An approval workflow with a small guarded editor attached | A full-featured database client in the browser |
| Who it is for | The team around the query — developers, DBAs, auditors | The person writing the query |
| Execution model | Submit, then wait for a DBA; a worker runs it asynchronously | Immediate — you run your statement and see the result |
| Statement guards | Parsed before running; WHERE-less UPDATE/DELETE rejected, LIMITs injected | Not the purpose; the client runs what you write |
| Data masking | PII masked in the result stream before it is stored | Not a client concern |
| Schema browsing | Minimal — this is not a client | Rich schema navigation, ER diagrams, data editing, import/export |
| Audit | Immutable log of requester, approver, statement, duration and rows | Depends on the database's own logging |
These two are often shortlisted together and shouldn’t be. They are not competitors; they occupy different rooms.
CloudBeaver is a client. It is DBeaver in a browser: connect, browse the schema, edit rows, run whatever you like, export the result. Its purpose is to make working with a database pleasant, and it is good at that.
QueryProxy is a gate. Its purpose is to make working with production data accountable. The editor it ships is small on purpose — enough to compose a statement with syntax highlighting and see the guard’s verdict before you submit, and nothing more. There is no schema tree to wander, because wandering a production schema is not the workflow being supported.
The execution model is the real difference
In a client, you run a statement and see the result. That immediacy is the whole value.
In QueryProxy, you submit a statement and wait. A DBA sees it in the queue or as a Slack card, approves or rejects it, and a queue worker executes it asynchronously — streaming the result row by row, masking PII as it writes, and recording every step. The delay is not an implementation detail to be optimised away. It is the product: it is where a second person looks at the query.
The arrangement that usually works
Give engineers a real client against development and staging, where exploration is free and mistakes are cheap. Point production at QueryProxy, and let it be the only route in. The people who want to browse a schema still can; the people who want production data get it reviewed, limited, masked and logged.
When to choose CloudBeaver instead
- Your engineers need a real database client — schema navigation, data editing, exports, ER diagrams. QueryProxy is not one and would frustrate anyone expecting one.
- The databases are development or staging, where free exploration is the point and an approval step is only friction.
- You want a graphical tool for a DBA's own daily work rather than a gate on other people's access.
Frequently asked
- Can QueryProxy replace CloudBeaver?
- Only if what you needed was a gate rather than a client. QueryProxy's editor exists to compose a request, not to explore a database — there is no schema tree, no data editing and no export designer. If your engineers rely on those, they still need a client.
- Can I use both?
- Yes, and the split is natural: a client like CloudBeaver or DBeaver pointed at development and staging, where free exploration costs nothing, and QueryProxy as the only path to production, where every statement is reviewed and every result masked.
- Why is there an editor in QueryProxy at all?
- Because a request has to be written somewhere, and writing it in a plain textarea loses the syntax highlighting and the guard feedback that stop a bad statement before it is ever submitted. The editor is a means to compose a request, not a workspace.