QueryProxy vs just-in-time access and PAM tools
Just-in-time access tools such as StrongDM grant access for a limited time and log and record it. QueryProxy sits at a different point, reviewing each SQL statement before it runs.
Updated:
At a glance
| Aspect | QueryProxy | Just-in-time access and PAM tools |
|---|---|---|
| Question answered | May this statement run? | May this person have access now, and until when? |
| Unit of control | One SQL statement | An access grant to a resource, for a period |
| Time limits | Not the model; a DBA grants a connection and each statement is approved | In StrongDM, access is granted just in time and expires automatically |
| Approval | A DBA approves every statement | In StrongDM access workflows, approvers accept or deny a request for access to a resource |
| Inside the granted window | Each statement is parsed, limited and approved | StrongDM logs and records access and activity; its policies can also require an approval workflow for an action, in the Enterprise plan |
| Result handling | PII masked while the result is written | Depends on the tool |
| Scope | SQL against five database engines | For StrongDM, databases, servers, Kubernetes clusters, clouds and web applications |
Just-in-time access and QueryProxy answer different questions, and the difference is the unit each one controls.
A just-in-time (JIT) access tool controls an access grant: this person may
reach this resource for this long. StrongDM, one product in the category,
describes this as granting least-privilege access just in time and expiring it
automatically (strongdm.com). QueryProxy controls
a statement: may this particular UPDATE run, and should the result be masked.
What does a grant not tell you?
A grant ends at the edge of the session. StrongDM’s page says it logs and records access and activity for audits. A recording tells you afterwards what a person ran; on its own it does not make anyone read the query first. Some tools add approval per action, as the next section shows.
QueryProxy reverses the order. The statement is parsed against the SQL guards, a DBA reads the exact SQL in the approval workflow, and only then does a worker run it. The record of that is an audit entry, not a recording of a session: there is no interactive session to record.
How do the approval models differ?
In StrongDM’s access workflows, users request access to resources and pre-selected approvers accept or deny; the page says the feature is part of the Enterprise plan. Statement-level rules exist in its policies, which can permit or forbid specific database commands and cap rows for Postgres and Microsoft SQL Server, again in the Enterprise plan. The policies page also lists, as a use case, allowing an action only if an approval workflow approves it. Hoop’s action access requests hold each command with status PENDING until a designated approver decides, in Slack, Teams or the web app. So approval before execution exists in some of these tools; the difference is whether it is the default for every statement.
These are two vendors’ features, not the whole category. This page does not claim to speak for every PAM product, and it does not define the term, since no primary definition was read for it. If your auditors use a specific definition of PAM, check what your product does against it.
How do they fit together?
Many teams need both. A JIT tool or bastion host controls the network path. Teleport does that with short-lived certificates. QueryProxy is where the database credential lives and where each statement is checked. That way, even a person with a valid grant cannot read the customers table without an approval and a masked result. The idea is laid out in what database access control is, and the quick start shows how to try it.
QueryProxy’s own limits apply here too. Its guards are static and best-effort, and database-side read-only execution is planned for v0.3.0; see production hardening.
StrongDM and Hoop statements above were read from their public documentation on 2026-10-13. Read your own vendor’s documentation for what your tool does.
When to choose Just-in-time access and PAM tools instead
- You need privileged access governed across servers, Kubernetes, cloud consoles and web applications. QueryProxy has nothing to offer outside SQL.
- Your control objective is time-boxed access with automatic expiry. QueryProxy does not issue time-limited access; it reviews statements.
- You need identity-provider integration across the whole estate, with approvals tied to tickets or a manager. QueryProxy approvers are DBAs inside the portal.
Frequently asked
- Is just-in-time access enough for production databases?
- Not on its own. It narrows when someone can connect, which is valuable. A grant alone does not decide what they run during that window, so a single DELETE without a WHERE inside a valid grant is still possible unless something reads the statement. Some tools add action-level controls, such as StrongDM policies and Hoop's action access requests.
- What is the difference between PAM and query approval?
- StrongDM, one PAM product, describes controlling access to resources and logging and recording it for audits. Query approval puts a second person on each statement before it executes. The first answers who and when, and the second answers what, though some access tools also offer approval per action.
- Is QueryProxy a PAM tool?
- No. It handles SQL against PostgreSQL, MySQL, MariaDB, SQL Server and SQLite, and issues no time-limited access to servers, clusters or consoles.
- Can I use JIT access and QueryProxy together?
- Yes. Use the access tool to decide who reaches the network and for how long, and let QueryProxy be the only holder of the database credential, so that everyday reads and writes go through a reviewed statement.