# QueryProxy vs Hoop.dev

> Hoop.dev alternative? Both are open source and sit in front of databases. Hoop runs a sidecar that masks and guards; QueryProxy is a portal with a DBA queue.

- Updated: 2026-10-13
- Source: https://queryproxy.com/compare/hoop-dev/
- Language: en-US
- Author: Muhammet Şafak

---
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.

## 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](https://github.com/hoophq/hoop) 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](https://hoop.dev/docs/gateway/overview)).
The control plane is marked "Part of Hoop Enterprise"
([hoop.dev/docs](https://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](https://hoop.dev/open-source)).

QueryProxy's [SQL guards](/docs/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](/docs/data-masking/) 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](/docs/sql-guards/)
states, and read-only execution on the database side is planned for v0.3.0
([production hardening](/docs/production-hardening/)).

## How do the review flows compare?

Hoop holds commands for people to decide. Its page on
[action access requests](https://hoop.dev/docs/learn/features/access-requests/action)
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](https://hoop.dev/docs/control-plane/slack.md)
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](/docs/approval-workflow/) is the whole
product: a DBA queue, buttons in [Slack](/docs/slack-integration/) and
[Teams](/docs/teams-integration/), 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](/what-is-database-access-control/). 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](/docs/quickstart/). Teams comparing approval portals will also want
the [Bytebase](/compare/bytebase/) and [Teleport](/compare/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.