Many Trino clusters become platform work
The hard part is no longer only running a query engine. It is repeating routing, catalogs, secrets, workers, lifecycle policy, and isolation for every team.
Product
XTrinode - A Control Plane for Trino
XTrinode lets data platform teams keep Trino as the query engine while turning each team or workload into a named Kubernetes runtime with routing, catalogs, scaling, lifecycle, and status.
The point is not another SQL engine. The point is the missing platform layer around many Trino runtimes: one gateway entrypoint, declarative runtime intent, reusable catalogs, elastic workers, and clear isolation boundaries.
BI tools
Notebooks
Trino CLI
Gateway route, balance, resume
API server leases and lifecycle
Operator desired state
analytics ready
etl KEDA
ad hoc suspended
Isolated runtimes with coordinators, workers, catalogs, and optional node pools.
The Product Boundary
XTrinode is the layer that turns repeated Trino cluster operations into one declarative runtime model.
The runtime is the contract
An XTrinode resource names the team or workload and carries size, worker bounds, suspend intent, route identity, catalog selection, and optional node-pool intent.
Intent stays reconciled
The operator turns the runtime into Kubernetes resources and status. The API server coordinates lifecycle calls. The gateway keeps SQL traffic pointed at usable backends.
Elasticity is part of the path
Idle runtimes can autosuspend, first query demand can resume them, and worker pools can stay fixed or follow KEDA signals such as gateway-observed query pressure.
Platform Shift
From Cluster Assembly To Runtime Intent
Standalone Trino deployments repeat the same platform work: Services, routing, worker counts, catalog files, secrets, scaling hooks, resource boundaries, and runbooks.
XTrinode makes that work a repeatable runtime model that can be reviewed, reconciled, observed, and evolved.
01 Request
A team asks for named Trino compute with size, routing, catalogs, and lifecycle intent.
02 Reconcile
The operator renders coordinators, workers, Services, catalog mounts, KEDA objects, and route state.
03 Route
The gateway sends SQL traffic to the right runtime by hostname, header, default route, or shared pool.
04 Operate
The platform can resize, suspend, resume, isolate, observe, and delete runtimes from declared state.
Where XTrinode Has An Edge
XTrinode keeps Trino as the engine and adds the operating layer needed for many isolated, routable, lifecycle-aware runtimes.
Trino runtimes become platform objects
XTrinode handles runtime creation, updates, status, suspend, resume, and cleanup through Kubernetes reconciliation instead of one-off deployment work.
Routing is runtime-aware
Hostname, header, default-route, and shared-pool routing are built in, with sticky query continuation and backend state enforcement.
Idle compute can sleep and wake
Autosuspend and gateway/API resume make disposable Trino compute practical for bursty BI, ETL, and ad hoc workloads.
Data access is reusable
XTrinodeCatalog keeps connector configuration and Secret-backed properties separate from runtime lifecycle and team sizing.
Workers scale per runtime
Teams can stay fixed for predictable capacity or use KEDA from gateway-observed query pressure when demand changes.
Boundaries are explicit
Namespaces, routes, catalogs, limits, size presets, and optional provider node pools give platform teams clearer ownership and chargeback.
Cluster Pieces
What The Control Plane Owns
The operator owns desired state, the API server owns coordinated lifecycle calls, and the gateway owns Trino-facing routing. Runtime resources remain visible Kubernetes objects rather than hidden service state.
Control Operator and API server for reconciliation and lifecycle coordination.
Query Gateway reverse proxy, route cache, sticky query routing, and auto-resume integration.
Compute Trino coordinator and workers per runtime, with fixed or KEDA-managed workers.
Catalogs XTrinodeCatalog resources, catalog ConfigMaps, and Kubernetes Secret references.
Isolation Namespaces, limits, routes, size presets, and optional provider node pools.
Packaging Helm charts, GHCR images, Terraform paths, and explicit provider validation posture.
Cloud Support Posture
Provider material is explicit about validation depth so platform teams can choose the right deployment path.
| Provider path | Current posture | Notes |
|---|---|---|
| GCP / GKE / CAPG | Fully exercised cloud path | Terraform, deploy automation, CAPG bootstrap, managed node-pool smoke coverage, and KEDA/resume smoke coverage. |
| AWS / EKS / CAPA | Experimental provider-validation path | Terraform, registry/deploy material, API-server auth wiring, and unit-tested node-pool resource generation exist. |
| Azure / AKS / CAPZ | Experimental provider-validation path | Terraform, registry/deploy material, API-server auth wiring, and unit-tested node-pool resource generation exist. |
Runtime Intent
Declare A Trino Runtime
The control plane is installed once. Workload teams request runtime compute with Kubernetes resources and route SQL through the gateway.
apiVersion: analytics.xtrinode.io/v1
kind: XTrinode
metadata:
name: runtime-a
namespace: team-a
spec:
size: s
minWorkers: 0
maxWorkers: 2
suspended: false
routing:
header: X-Trino-XTrinode=team-a/runtime-a