Heavy BI Users
Serve BI tools and analyst teams through a stable SQL endpoint while the platform routes each request to the appropriate runtime.
Kubernetes-native Trino control plane
XTrinode
Give BI-heavy teams, burst ETL jobs, and ad hoc users a governed path to elastic Trino compute without making every workload a custom deployment.
For Workloads That Change Shape
XTrinode helps teams offer full Trino capability for workloads that do not fit a single always-on cluster model.
Disposable Compute
Provision runtime capacity for a team, investigation, or short-lived workload, then let idle compute auto-suspend or retire.
ETL On Demand
Give read-heavy or write-heavy ETL dedicated sizing, KEDA behavior, and optional provider node-pool capacity.
Full Trino Runtime
Keep the Trino engine, SQL behavior, and ecosystem compatibility while standardizing lifecycle, routing, scaling, and operations.
One Install. Many Trino Runtimes.
Install the control plane once, then offer consistent Trino runtime creation, routing, scaling, catalog mounting, and lifecycle operations to teams.
Named Trino compute
Each XTrinode resource maps to a coordinator, workers, catalogs, routing identity, lifecycle state, and ownership boundary.
Stable SQL entrypoint
Clients connect by hostname, header, default route, or shared pool while coordinator services remain behind the platform boundary.
Auto-resume and auto-suspend
Use fixed workers for predictable cases, or let KEDA respond to gateway query pressure, wake suspended runtimes, and return idle compute to a smaller footprint.
Controlled data access
XTrinodeCatalog keeps catalog wiring separate from runtime lifecycle. Typed connector coverage is growing; custom properties remain available.
Machine and namespace boundaries
Separate runtimes can use separate namespaces, routes, limits, catalogs, size presets, and optional per-runtime node pools.
Operational clarity
Status, Kubernetes events, gateway route state, auto-resume leases, auto-suspend policy, and lifecycle APIs give operators clear signals.
Operating Model
From Cluster Assembly To Runtime Intent
At scale, standalone Trino deployments repeat the same operational work: services, routing, worker counts, catalog files, secrets, scaling hooks, resource boundaries, and runbooks.
XTrinode turns that repeated platform work into Kubernetes resources that can be reviewed, reconciled, observed, and evolved.
01 Declare
Create a runtime resource with size, catalogs, routing, scaling, and lifecycle intent.
02 Reconcile
The operator renders Trino resources, catalog mounts, KEDA objects, and gateway routes.
03 Route
The gateway selects a running backend by hostname, header, shared pool, or default route.
04 Operate
Auto-resume, auto-suspend, resize, isolate, troubleshoot, and delete runtimes from declared state.
Release Path
Built For Platform Ownership
XTrinode aligns Helm chart versions and component image versions. Control-plane images use GHCR, while the managed Trino runtime image is pinned separately.