QueryProxy vs Hoop.dev
Hoop.dev is an MIT-licensed project whose repository describes runtime enforcement that masks sensitive data and blocks destructive commands from AI agents. QueryProxy is an AGPL-3.0 portal where people submit SQL and a DBA approves it.
Updated:
At a glance
| Aspect | QueryProxy | Hoop.dev |
|---|---|---|
| Shape | A web portal with a queue, a worker and a scheduler in one container | A sidecar, a single binary run next to the database, with a control plane for a fleet of sidecars; a separate Enterprise gateway covers engineers and agents |
| License | AGPL-3.0 | MIT for the open-source edition; an Enterprise edition requires a license |
| Protocols (Hoop sidecar) | PostgreSQL, MySQL, MariaDB, SQL Server and SQLite | PostgreSQL, Microsoft SQL Server and HTTP |
| Statement guards | Parser-based rules on every submission, with no per-user configuration | Guardrails configured in a rule file; one guardrail per sidecar in the free edition |
| Data masking | Column-pattern and content-regex rules, applied while results are written | Rewrites sensitive values in the response in memory; one rule per sidecar in the free edition |
| Human review | A DBA approves each statement in the web queue or from Slack or Teams | Hoop holds a command until a designated approver decides, in Slack, Teams or the web app; the README lists the control plane's review queue as not yet built |
| Typical caller | A person writing SQL in a browser | Engineers, AI agents and service accounts through the gateway; applications and agents through the sidecar port |
Short answer: for an engineer who needs a second person to read SQL before it runs, either can do the job. For an application or AI agent that connects through a database driver, only Hoop can, because QueryProxy has no port to point one at. Both projects are open source, both mask results, and both put something between a caller and a database.
Hoop’s repository describes the project as open-source enforcement at runtime that masks sensitive data and blocks destructive commands from AI agents. The unit of deployment is a sidecar: a single binary with one config file, run next to your database, with callers changing only the port in their connection string. Hoop’s documentation also describes a control plane for running many sidecars, and a Gateway, “a layer 7 gateway that sits between engineers, AI agents, service accounts and your infrastructure” (hoop.dev/docs/gateway/overview). The control plane is marked “Part of Hoop Enterprise” (hoop.dev/docs), and the Gateway is licensed as Enterprise.
QueryProxy starts from the person. A developer opens Query Studio, writes SQL against a connection a DBA granted, and the statement waits in a queue. Nothing connects to QueryProxy with a database driver; there is no port to point an application at.
How do the guards compare?
Hoop’s README lists Data Masking, Guardrails and a Session Analyzer for each of PostgreSQL, Microsoft SQL Server and HTTP. The open-source page says the free edition includes one guardrail and one data masking rule per sidecar, and that the Enterprise edition lifts those limits (hoop.dev/open-source).
QueryProxy’s SQL guards are not rules you write. They are
fixed: a write needs a WHERE, a read gets a LIMIT, and a list of
server-level statements is refused. Masking rules are
yours, by column-name pattern or content regex, and applied while the result
is written, so the unmasked version is not stored. QueryProxy tells you where
its limits are: guard coverage for MySQL, MariaDB and SQL Server has not been
run against live servers, which the guards reference
states, and read-only execution on the database side is planned for v0.3.0
(production hardening).
How do the review flows compare?
Hoop holds commands for people to decide. Its page on
action access requests
says the command is held with status PENDING, designated approvers are notified
in Slack, Teams or the web app, and an approved command runs and returns its
results. For the sidecar, the Slack page
describes a require_review rule: held statements are posted to Slack and one
approval releases them. Separately, the README lists the control plane’s review
queue actions (approve, reject, retry) as not yet built. Project status changes
quickly, so read the current documentation on the day you decide.
QueryProxy’s approval workflow is the whole product: a DBA queue, buttons in Slack and Teams, no self-approval (an administrator override is flagged in the log), and an audit log that cannot be edited.
Which should you pick?
If an application or an AI agent needs a guarded path through a database driver, QueryProxy cannot give it one and Hoop’s sidecar can. If the thing that needs guarding is the engineer who reads production data once a week, and the missing piece is a second person reading the query, both can hold the command; that is what QueryProxy is for. Choose on the other differences: QueryProxy is one AGPL-3.0 container with every feature and fixed parser rules, while Hoop’s free edition limits guardrails and masking to one rule each per sidecar. To try QueryProxy, start with the quick start. Teams comparing approval portals will also want the Bytebase and Teleport pages.
Claims about Hoop above were checked against its public repository and documentation on 2026-10-13. Enterprise terms are not published there; ask Hoop.
When to choose Hoop.dev instead
- Your callers are applications or AI agents that connect through a database driver. QueryProxy is a place for a person to submit SQL, not a proxy that a client library can be pointed at.
- You need HTTP traffic covered by the same masking and guardrails. Hoop's README lists HTTP among its protocols; QueryProxy accepts SQL only.
- You want enforcement that sits next to the database as a single binary with one config file, rather than a portal with a queue and a database of its own.
Frequently asked
- Is QueryProxy a Hoop.dev alternative?
- For people who need a second person to approve ad-hoc SQL, yes, though Hoop can hold commands for approval too, so QueryProxy is not the only option there. For applications and AI agents that connect through a database driver, no, because QueryProxy has no driver-level proxy to point them at. Check which of those two callers you have before comparing features.
- Are both open source?
- Yes, under different licenses. Hoop's repository is labelled MIT and QueryProxy is AGPL-3.0. Hoop also sells an Enterprise edition that requires a license, while QueryProxy has no paid tier.
- How do the approval flows differ?
- Both hold a command until a person decides. Hoop's documentation describes per-command access requests with designated approvers notified in Slack, Teams or the web app. QueryProxy sends every statement through one DBA queue, with Slack and Teams buttons, no self-approval (an administrator override is flagged in the log) and an audit log that cannot be edited. The README also lists the control plane's review queue actions as not yet built, so re-read it before deciding.
- Which one needs fewer moving parts?
- A Hoop sidecar is one binary and one config file. QueryProxy is one container, but that container runs a portal, a queue worker and a scheduler, and keeps its own application database.