# QueryProxy vs Teleport

> Teleport controls who reaches your infrastructure; QueryProxy controls what they run once there. Different halves of the problem, often used together.

- Updated: 2026-09-08
- Source: https://queryproxy.com/compare/teleport/
- Language: en-US
- Author: Muhammet ŞAFAK

---
Teleport is an identity-aware access proxy for infrastructure — SSH, Kubernetes, databases and internal web apps — issuing short-lived certificates instead of standing credentials. QueryProxy sits one layer up and reviews the individual SQL statement.

## At a glance

| Aspect | QueryProxy | Teleport |
| --- | --- | --- |
| Question answered | May this statement run? | May this person connect? |
| Protocols | SQL only, over the databases it proxies | SSH, Kubernetes, databases, internal web apps, Windows desktops |
| Per-statement review | Every query is parsed, guarded and approved before it runs | Not the design; sessions are recorded and audited rather than pre-approved |
| Approval workflow | A DBA approves each query from the web or from Slack/Teams | Access Requests approve a role or a session, not an individual query |
| Result handling | Results are limited and PII-masked before they touch disk | Results pass through; the session is recorded |
| Licensing | AGPL-3.0, every feature | Open-source core with a commercial enterprise edition |
| Footprint | One container plus a worker | A cluster component with certificate authority and identity integration |

The clearest way to tell these apart is the question each one answers.

Teleport asks **"may this person connect?"** It authenticates an engineer
against your identity provider, issues a short-lived certificate instead of a
standing password, brokers the connection, and records the session. That model
covers SSH, Kubernetes, internal web apps and databases alike, which is its real
strength: one access story for the whole estate.

QueryProxy asks **"may this statement run?"** It never issues a credential to
anyone. The developer writes SQL in the portal, the AST inspector rejects an
`UPDATE` or `DELETE` with no `WHERE` and clamps a runaway `SELECT`, a DBA
approves it, and only then does a queue worker execute it — with the results
masked as they stream to disk.

## Why the distinction matters

A bastion or an access proxy can tell you that a named engineer opened a
connection to the customers database at 14:02. It cannot, by construction,
prevent the `DELETE FROM customers` they type thirty seconds later. Session
recording means you will know exactly what happened, in detail, afterwards.

QueryProxy is the opposite trade: far narrower reach, but the statement is read
before it runs and someone else has to agree to it.

## Using them together

These compose rather than compete. Teleport governs the network path and the
identity; QueryProxy holds the database credential and reviews the query. A
common arrangement is Teleport for engineer access to infrastructure generally,
and QueryProxy as the only route to production data — so that even an engineer
with a valid Teleport identity cannot read the customers table without an
approval and a masked result.

## When to choose Teleport instead

- You need to govern more than databases. Teleport covers SSH, Kubernetes and internal apps under one identity model, and QueryProxy has nothing to say about any of them.
- Your requirement is short-lived credentials and session recording tied to an SSO identity, rather than review of the statement itself.
- You want interactive sessions where an engineer explores freely, with the recording as the control. QueryProxy's model is one submitted statement at a time.

## Frequently asked

### Is QueryProxy a Teleport alternative?

Not really — they answer different questions. Teleport decides who may connect and issues a short-lived credential; QueryProxy decides whether a specific statement may run and what comes back. Teams with Teleport already deployed still use QueryProxy for the approval step, and the two compose cleanly.

### Can I run both?

Yes, and it is a sensible combination. Teleport governs reaching the network and the host; QueryProxy holds the database credential and gates the individual query, masking the result. Each covers what the other does not.

### Does QueryProxy replace session recording?

No. QueryProxy keeps an immutable audit log of who asked, who approved, what ran, how long it took and what it touched — but there is no interactive session to record, because there is no interactive session. That is the point of the design.