Deploy Trino

Deploy and Host Trino on Railway

Trino is a distributed SQL query engine for fast analytic queries across data that lives in many places at once. It began at Facebook as Presto, was renamed by its creators in 2020, and is now the query layer behind analytics at Netflix, Shopify and LinkedIn. One ANSI SQL statement can join a Postgres table to files in an S3 data lake, an Iceberg table or a Kafka topic — no ETL job, no copy of the data, no proprietary storage format.

Self-host Trino on Railway and you get the real cluster shape, not one container pretending to be a cluster: a coordinator that parses SQL, plans queries and serves the web interface, two dedicated worker services that do the scanning and joining, and a Postgres database wired up as a live catalog you can query the moment the deploy finishes. Only the coordinator has a public URL, and password authentication protects the web interface, the CLI, JDBC and the REST API. Workers stay on the private network, authenticated by a shared secret.

Getting Started with Trino on Railway

Open the coordinator's public URL and you land on a login screen. Sign in as admin with the password in the coordinator's TRINO_PASSWORD variable, which the template generates; change it in the Railway dashboard whenever you like, since the credential is rebuilt from that variable on every restart. The first screen is the cluster overview — check that Active workers reads 2, confirming both workers registered. Then run something: the image ships the tpch and tpcds catalogs, which generate benchmark data on demand, so SELECT count(*) FROM tpch.sf1.orders is a real distributed query needing no setup. Point the Trino CLI or a JDBC client at https:// on port 443, or POST SQL to /v1/statement. To see federation end to end, write generated data into Postgres with CREATE TABLE postgresql.public.top_nations AS SELECT ... FROM tpch.tiny.orders ..., then join that new table back against tpch in one query. Every query appears in the web interface with its plan, stage timings and split timeline.

About Hosting Trino

Trino separates the query engine from storage. It owns no data: connectors translate ANSI SQL into whatever each source speaks, and results stream through memory instead of landing on disk between stages, which is why interactive queries return in seconds where a batch engine takes minutes. Teams self-host it to put one SQL endpoint in front of a sprawl of databases and object storage, instead of paying a vendor to hold a second copy of their data.

• Federated queries — join Postgres, MySQL, MongoDB, Kafka, Iceberg, Delta Lake, Hive and 50+ other sources in one statement
• ANSI SQL — window functions, CTEs, correlated subqueries, geospatial and JSON functions
• Massively parallel execution — work is split across every worker in the cluster
• Standard clients — JDBC and ODBC drivers, a Python client, dbt and Superset integrations
• Pluggable security — file, LDAP or OAuth 2 authentication, per-catalog access rules

The services map onto Trino's own roles: the coordinator plans SQL, schedules work and serves the web interface and client protocol; each worker executes the splits it is handed, spilling to its volume when a join outgrows memory; Postgres is a demonstration catalog and a good place to land results. All three Trino services run one image and switch role from a single variable.

Why Deploy Trino on Railway

Railway removes the operational overhead of a distributed cluster.

• Private networking between coordinator and workers, no VPC to configure
• Add a worker service in one click when queries need more parallelism
• Persistent volumes for query spill, attached to each worker
• Managed Postgres provisioned and wired into the catalog automatically
• HTTPS, health checks and automatic restarts included

Common Use Cases

• Query production data safely — point analysts at a read replica through Trino rather than handing out database credentials
• Data lake analytics — SQL directly over Parquet, ORC, Iceberg or Delta Lake files in object storage, no loading step
• A SQL layer for BI tools — one endpoint for Superset, Metabase, Tableau or dbt, reaching every source

Dependencies for Trino

• Trino (trinodb/trino:483) — coordinator and both workers, built from gridalpha/trino-railway, which adds Railway startup configuration to the official image
• PostgreSQL (ghcr.io/railwayapp-templates/postgres-ssl:18) — a live catalog to query and write to

Environment Variables Reference

Deployment Dependencies

• Source repository: github.com/gridalpha/trino-railway
• Upstream project: github.com/trinodb/trino
• Container image: hub.docker.com/r/trinodb/trino
• Documentation: trino.io/docs/current

Hardware Requirements for Self-Hosting Trino

Trino sizes its heap from the container's memory limit, so raising a service's memory raises the query memory on that node. Scale out with more worker services rather than replicas: every node needs its own identity and private hostname, which replicas share.

Self-Hosting Trino

The official image runs a single-node cluster with no configuration. This is the Docker command:

docker run --name trino -d -p 8080:8080 trinodb/trino:483
docker exec -it trino trino

A real cluster needs a coordinator and workers agreeing on a discovery URI and a shared secret, with a config directory mounted at /etc/trino on each node. The coordinator's config.properties:

coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
discovery.uri=http://coordinator:8080
internal-communication.shared-secret=<a>
http-server.process-forwarded=true
http-server.authentication.type=PASSWORD

Workers use the same file with coordinator=false and no authentication block. Catalogs are one properties file per source in /etc/trino/catalog, and every node needs an identical copy — a catalog present only on the coordinator makes queries against it fail. This template generates all of it from variables at startup.

How Much Does Trino Cost to Self-Host?

Trino is free and open source under the Apache 2.0 licence, with no paid edition, seat limits or feature gates — connectors, fault-tolerant execution and security are all in the community build. Starburst sells support and a managed service, but nothing is held back for them. Self-hosting on Railway costs only the compute and storage the cluster uses.

FAQ

What is Trino? Trino is an open-source distributed SQL query engine, formerly PrestoSQL, that runs fast analytic queries against data held in other systems. It is a query engine, not a database: it stores nothing itself.

What does this Railway template deploy? A Trino coordinator with a public URL and password authentication, two workers on the private network with volumes for query spill, and a managed Postgres database wired up as a queryable catalog.

Why does the template include a Postgres database? It gives the cluster a real data source from the first minute — somewhere to create tables, write results and see federation working against something other than generated data.

How do I connect the Trino CLI or a JDBC client to a self-hosted Trino cluster? Use trino --server https:// --user admin --password, or the JDBC URL jdbc:trino://:443/, with the web interface's credentials.

How do I add a data source to self-hosted Trino? Each source is a properties file in /etc/trino/catalog naming a connector and its details. Here the Postgres catalog is generated from variables at startup; add more by extending the source repository, keeping every node's catalogs identical.

Can I add more Trino workers on Railway? Yes. Duplicate a worker service, keep its variables identical, and it registers with the coordinator on first boot. Adding services rather than replicas keeps each node's identity and hostname unique.