One SQL endpoint for every engine and agent

Clients speak

Trino HTTP
PostgreSQL wire
MySQL wire
Snowflake HTTP
Snowflake SQL API
Arrow Flight SQL
MCP
Trino HTTP
PostgreSQL wire
MySQL wire
Snowflake HTTP
Snowflake SQL API
Arrow Flight SQL
MCP

Queries land on

Trino
DuckDB
StarRocks
Athena
ClickHouse
MySQL
Snowflake (ADBC)
Databricks (ADBC)
BigQuery (ADBC)
Redshift (ADBC)
Trino
DuckDB
StarRocks
Athena
ClickHouse
MySQL
Snowflake (ADBC)
Databricks (ADBC)
BigQuery (ADBC)
Redshift (ADBC)

Built for agents

Follow a query through QueryFlux

From an agent question to a Studio trail: guardrails, dialect translate, routing, cache, then the engine that should run it. Connect an agent →

You asked

How many US events landed in the last 7 days?

AI agentMCP client

Control planeQueryFlux

guardrailstranslateroutecache

DuckDBagent scratchpad
Trinoetl
StarRocksBI

Incoming · Trino SQLSELECT date_trunc('day', ts) AS d, count(*) AS n FROM events WHERE country = 'US' AND ts >= date_add('day', -7, now()) GROUP BY 1

From Trino

SELECT date_trunc('day', ts) AS d,
       count(*) AS n
FROM events
WHERE country = 'US'
  AND ts >= date_add('day', -7, now())
GROUP BY 1

To DuckDB

SELECT date_trunc('day', ts) AS d,
       count(*) AS n
FROM events
WHERE country = 'US'
  AND ts >= now() - INTERVAL 7 DAY
GROUP BY 1

The agent asks over MCP

The AI agent calls queryflux.run_query — one endpoint, no warehouse credentials on the client.

01MCP · streamable HTTP

One MCP endpoint

Point Claude Code, Cursor or Claude Desktop at one URL. Agents get tools to run queries, list schemas, describe tables, read the engine plan, and check or cancel what they started.

02agent context · session replay

Every query has an owner

Each query records the agent, conversation, step and tool call behind it. Replay a conversation step by step in Studio and see exactly what the agent ran, and what was blocked.

03read-only · row limits · Python · webhooks

Guardrails in the query path

Block writes, cap result sizes, require a WHERE clause on the tables you choose, or call your own Python or webhook check. Guardrails run in QueryFlux itself, so they hold whether an agent connects over MCP or a SQL driver.

04OPA · Cerbos

Policies agents can’t talk their way around

Row filters and column masks from OPA or Cerbos apply to agents like any other user. Route agents to their own group with its own concurrency limit, so a busy agent queues instead of starving your dashboards.

The multi-engine tax

Every new engine multiplies the glue code

Most data platforms already run more than one engine. Without a routing tier, each one adds drivers, conventions, and dashboards that someone has to keep in sync.

Without QueryFlux

01
N × M driver configs
Every client wired to every engine — connection strings drift per team.
02
Wrong engine, wrong bill
CPU-heavy joins land on scan-priced engines and the other way round.
03
Noisy neighbours
A batch ETL job and a live dashboard fight over the same cluster.
04
Dialect rewrites
Moving a workload means rewriting SQL across every tool that sends it.
05
Fragmented visibility
One UI per engine, no shared view of queues, latency, or cost.

With QueryFlux

A control plane in front of your engines

Topology becomes config, not code. Add an engine, change a rule, or swap a backend without touching a single client.

One endpoint, native protocols — clients keep the drivers they already have
Rule-based routing by protocol, header, tag, regex, or a Python function
Per-group concurrency caps with proxy-side queueing and fallback groups
sqlglot dialect translation when client and engine disagree
Prometheus metrics, query history, and Studio across every engine

Architecture

How a query flows through QueryFlux

Every query passes through the same pipeline, whichever protocol it arrived on. Read the system overview →

01
Clients
Unchanged drivers & tools
- BI dashboards
- dbt / Airflow
- Notebooks
- AI agents (MCP)
02
Frontends
Native wire protocols
- Trino HTTP
- PostgreSQL
- MySQL
- Snowflake
- Flight SQL
03
Router
First matching rule wins
- protocol
- header
- tags
- queryRegex
- pythonScript
- compound
04
Translate & admit
Per cluster group
- sqlglot dialects
- Concurrency caps
- Queue & fallback
- Access control
05
Engines
Load-balanced members
- Trino
- StarRocks
- DuckDB
- Athena
- ADBC
06
Observe
One pane of glass
- Prometheus
- Query history
- Studio
- Admin API

Capabilities

Route, contain, understand — over engines you already run

One control point between your clients, your agents and your engines: it decides where each query runs, what it may do, and keeps the record.

Route

Send each query to the engine that should run it, by protocol, user, tags, SQL pattern or a Python rule. Translate the dialect on the way, and move traffic between engines by weight with no client changes.

Under the hoodRouter chain · sqlglot · weighted groups

Contain

Cap running queries per engine across every replica and worker, and queue the rest. Block writes, cap rows, require a WHERE clause on chosen tables, and apply row filters and column masks from OPA or Cerbos.

Under the hoodCapacity limits · guardrails · access control

Understand

See every query with its user or agent, the route it took, its timings and its guardrail decisions. Prometheus metrics, Grafana dashboards, and Studio for history, routing and replay.

Under the hoodQuery history · Prometheus · Studio

Open

Any engine, any protocol, in your environment. Apache-2.0, written in Rust, about 0.35 ms of p50 overhead. Your clients keep their drivers; your engines stay replaceable.

Under the hoodApache-2.0 · Rust · self-hosted

Use cases

What teams route through QueryFlux

Routing, capacity limits, and load balancing — one proxy, every client, no separate stack per engine.

01protocolBased · queryRegex

Multi-engine data platform

BI tools connect over MySQL wire and land on StarRocks, scheduled jobs stay on Trino, and ad-hoc SELECT * exploration is matched by regex and sent to Athena — no new connection strings for your teams.

02pythonScript

Cost-aware workload dispatch

A Python router inspects every query and steers CPU-heavy joins and windows to compute-priced Trino while scan-heavy Iceberg reads go to scan-priced Athena. Encode the cost model once; every client inherits it.

03maxRunningQueries · queueing

Dashboard SLA protection

Cap the StarRocks group with maxRunningQueries so dashboards always have headroom. When it is full, ad-hoc queries wait in line at the proxy instead of reaching StarRocks — and Grafana shows queue depth live.

04weighted load balancing

Transparent engine migration

Run Trino and StarRocks in one group and ramp StarRocks from 10% to 100% with zero client changes. Studio query history lines up per-engine latency until you are ready to flip the weights.

In production

Built to sit in front of everything

Identity, migrations, fleet-wide limits and deployment: the parts that decide whether a proxy survives contact with real traffic.

01passthrough · impersonation · token exchange

Agents query as the person they work for

No shared warehouse password for every agent. QueryFlux can pass the caller’s own credential through, run the query as that user on Trino or ClickHouse, or exchange their token for one the engine accepts. The engine’s own permissions and audit log still apply.

02Snowflake wire · dialect translation

Move off an engine without touching a client

Snowflake clients connect to QueryFlux as if it were Snowflake, and their queries can run on Trino, StarRocks or DuckDB instead. The connection string stays the same; the engine behind it is your choice.

03capacity quotas · fair queueing

One limit across the whole fleet

A cluster’s concurrency limit holds across every replica and worker. Queries that have to wait are served first come, first served: in our capacity benchmark, waits dropped from 3–14 s to about 0.1 s at p99.

04worker mode · Helm

A worker next to every app

Run one proxy, a set of replicas, or a QueryFlux worker beside each application, as a sidecar or one per node. Workers take config, limits and history from a control plane and never touch its database.

FAQ

Questions teams ask first

Do I have to move my data?

No. QueryFlux sits in front of the engines you already run and forwards queries to them. Your data stays where it is.

Which engines and clients does it work with?

Clients connect over Trino HTTP, PostgreSQL, MySQL, Snowflake, Arrow Flight SQL or MCP. Queries run on Trino, DuckDB, StarRocks, ClickHouse, Athena and MySQL, and through ADBC on Snowflake, BigQuery, Databricks, Redshift, PostgreSQL and more.

How does it decide which engine runs a query?

Routing rules you write, checked in order: by protocol, user, tags, a SQL pattern, or a Python function. The first match picks a cluster group, and the group spreads queries across its members. See routing.

How do I stop an agent from doing damage?

Turn on guardrails (read-only, row limits, a required WHERE clause on chosen tables, or your own Python or webhook checks) and access policies with row filters and column masks. They run in the query path for every protocol. Route agents to their own group with its own concurrency limit, so they can't crowd out other work. See guardrails.

Can I see what an agent did?

Yes. Every query records the agent, conversation, step and tool call, and Studio replays a conversation step by step. See agentic AI.

Where does it run?

In your environment. QueryFlux is Apache-2.0 open source: run it with Docker or Helm, as one proxy, a set of replicas, or workers next to your applications.

How much latency does it add?

About 0.35 ms at p50 on the proxy path, measured with the benchmark in the repo. See benchmarks.

Start building