DataFlowsAI TrinoX
TrinoX architecture

Standalone Rust engine with a Trino-compatible surface

TrinoX is a standalone Rust query engine exposing Trino-compatible HTTP, plus an in-tree distributed execution path. Clients, wire protocol, and coordinator semantics stay familiar; the performance-critical path is native columnar execution over open table formats.

Summary

Standalone Rust SQL engine + Trino-compatible HTTP protocol + native vectorized execution + local Parquet/Iceberg catalog + optional distributed coordinator/worker runtime.

High-level shape

TrinoX query path from client to results Client CLI · REPL · Trino HTTP POST /v1/statement trino-server Query lifecycle · wire protocol · coordinator state HTTP /v1/statement polling & cancellation SQL Frontend sqlparser-rs · Trino dialect Analyzer · name & type resolution Planner Logical plan → optimized physical plan Optional distributed stage DAG execution mode Single-node executor Local pipelines · in-process scheduler Native execution kernels Scan · filter · project · join · aggregate Columnar batches · SIMD paths · spill-aware ops Distributed scheduler Stage DAG · split placement · workers Worker RPC + exchange Repartition · broadcast · local exchange Partial/final agg · distributed joins Results Arrow / RecordBatch → Trino wire JSON Query pipeline Ingress Coordinator Compile Plan Local exec Distributed Output

Hand-drawn-style diagram inspired by Excalidraw. Colors follow the query path: ingress → coordinator → compile → plan → execution → output.

Crate split

trino-parser

SQL parsing

Wrapper around sqlparser-rs for the Trino dialect surface.

trino-catalog

Table discovery

Connectors for Parquet, Iceberg, Delta, and related metadata chains.

trino-planner

Planning

Analyzer, optimizer, physical planning, and distributed stage planning.

trino-server

Runtime hub

Executor, CLI, HTTP server, distributed scheduler, worker, exchange, auth, cache, metrics, spill, and FTE plumbing.

trino-node

Node entrypoint

Small node-local binary for worker/coordinator roles.

Layout

trinox/crates/

All production crates live under a single workspace tree; the demo site you are using mounts the HTTP surface from the integrated service.

Execution flow

  1. SQL enters through CLI, REPL, or the Trino HTTP protocol (/v1/statement).
  2. Parser and analyzer resolve names, types, subqueries, and expressions.
  3. Planner builds logical and physical plans — joins, aggregates, scans, sorts, limits, and distributed stage fragments when needed.
  4. Executor runs native columnar pipelines over table data.
  5. Catalog layer discovers data from local Parquet directories and Iceberg metadata chains.
  6. Output returns as CLI text or Trino wire-compatible JSON.

Native operator layer

The performance-critical path is native Rust/SIMD execution. Internally, execution is columnar and batch-oriented.

Scan & filter

  • Scan + predicate pushdown
  • SIMD numeric filters
  • Varchar equality / LIKE / IN-list filters

Compute & aggregate

  • Projection and expression evaluation
  • Hash aggregation (Swiss-table-style)
  • Sort / top-N

Join & spill

  • Hash join build/probe
  • Semi/anti/outer join variants
  • Spill-aware execution paths
  • Exchange serialization for distributed mode

Server and distributed mode

trino-server supports both single-node and clustered operation:

Single node
  • HTTP server compatible with Trino clients
  • Coordinator-owned query lifecycle
  • Local pipeline execution end-to-end
Distributed
  • Worker registration and heartbeats
  • Stage DAG scheduling and split placement
  • Cross-process exchange (repartition / broadcast / local)
  • Partial and final aggregation shapes
  • Broadcast/repartition join planning
  • Distributed top-N / final merge stages
  • Cancellation, cleanup, retry policy, exchange spool / FTE

Agent factory (how TrinoX is built)

DataFlowsAI ships systems through a continuous SPEC → IMPLEMENT → VERIFY → FUZZ → SHIP pipeline. The pipeline page simulates one run; production development follows the same artifact boundaries.

Continuous

AI agent factory

Upstream docs, RFCs, and tests become typed specs; planner/coder/reviewer agents implement; property, differential, and formal verification gate releases; SQLancer-style fuzzing and DST soak before ship.

Customer surface

No client change

trino-cli, JDBC, Python trino, dbt, and BI tools keep using the same wire protocol — point the coordinator URL at TrinoX.