Extending QueryFlux
This guide separates two ideas that are easy to conflate:
| Concept | Meaning | Example |
|---|---|---|
| Backend engine | A cluster type QueryFlux routes queries to. It has an adapter that talks to the real database (HTTP, MySQL wire, embedded library, AWS SDK, …). | Trino, DuckDB, StarRocks, Athena |
| Frontend protocol | How clients connect to QueryFlux (ingress). SQL enters with a FrontendProtocol and a default source dialect for translation. | Trino HTTP, PostgreSQL wire, MySQL wire, Flight SQL |
Adding PostgreSQL wire as a client entrypoint is not the same as adding “PostgreSQL” as a backend: today, PostgresWire is already a frontend in queryflux-frontend; traffic still lands on the shared dispatch path and is sent to whatever backend adapter routing chose (often Trino).
Guides
| Page | What it covers |
|---|---|
| Backend | Rust adapter (EngineAdapterTrait, EngineAdapterFactory), registered_engines (all_factories), persistence, dispatch notes — plus QueryFlux Studio (StudioEngineModule, catalog, forms). |
| Frontend | New ingress protocol: listener, FrontendProtocol, dispatch, optional protocol-based routing, admin frontends snapshot. Existing protocols: Frontends. |
Related reading
- Frontends — Trino HTTP, Postgres wire, MySQL wire, Flight SQL
- system-map.md — End-to-end flow
- query-translation.md — Dialects and sqlglot
- routing-and-clusters.md — Routers and groups
- observability.md — Admin API (including engine registry JSON)