---
title: "Deploy Trino"
description: "Distributed SQL query engine for databases, data lakes, and analytics."
category: "Analytics"
url: https://railway.com/deploy/trino
---

# Deploy Trino

Distributed SQL query engine for databases, data lakes, and analytics.

**[Deploy Trino on Railway](https://railway.com/template/trino)**

- **Creator:** INF Labs
- **Category:** Analytics

## Template content

### trino-worker-3 https://www.gravatar.com/avatar/3d2bf4c90da61ec926b494b98fbb3851?s=120&r=g&d=404

- **Image:** trinodb/trino:483
- **Start command:** `/bin/bash -c 'printf "%s\n" "coordinator=false" "http-server.http.port=8080" "discovery.uri=http://trino-coordinator.railway.internal:8080" > /etc/trino/config.properties; printf "%s\n" "node.environment=${TRINO_ENVIRONMENT}" "node.id=${TRINO_NODE_ID}" "node.data-dir=/data/trino" > /etc/trino/node.properties; exec /usr/lib/trino/bin/run-trino'`

### trino-coordinator https://www.gravatar.com/avatar/3d2bf4c90da61ec926b494b98fbb3851?s=120&r=g&d=404

- **Image:** trinodb/trino:483
- **Start command:** `/bin/bash -c 'printf "%s\n" "coordinator=true" "node-scheduler.include-coordinator=false" "http-server.http.port=8080" "http-server.process-forwarded=true" "discovery.uri=http://trino-coordinator.railway.internal:8080" "catalog.management=dynamic" > /etc/trino/config.properties; printf "%s\n" "node.environment=${TRINO_ENVIRONMENT}" "node.id=${TRINO_NODE_ID}" "node.data-dir=/data/trino" > /etc/trino/node.properties; exec /usr/lib/trino/bin/run-trino'`
- **Public domain:** Yes

### trino-worker-2 https://www.gravatar.com/avatar/3d2bf4c90da61ec926b494b98fbb3851?s=120&r=g&d=404

- **Image:** trinodb/trino:483
- **Start command:** `/bin/bash -c 'printf "%s\n" "coordinator=false" "http-server.http.port=8080" "discovery.uri=http://trino-coordinator.railway.internal:8080" > /etc/trino/config.properties; printf "%s\n" "node.environment=${TRINO_ENVIRONMENT}" "node.id=${TRINO_NODE_ID}" "node.data-dir=/data/trino" > /etc/trino/node.properties; exec /usr/lib/trino/bin/run-trino'`

### trino-worker-1 https://www.gravatar.com/avatar/3d2bf4c90da61ec926b494b98fbb3851?s=120&r=g&d=404

- **Image:** trinodb/trino:483
- **Start command:** `/bin/bash -c 'printf "%s\n" "coordinator=false" "http-server.http.port=8080" "discovery.uri=http://trino-coordinator.railway.internal:8080" > /etc/trino/config.properties; printf "%s\n" "node.environment=${TRINO_ENVIRONMENT}" "node.id=${TRINO_NODE_ID}" "node.data-dir=/data/trino" > /etc/trino/node.properties; exec /usr/lib/trino/bin/run-trino'`

## Documentation

# Deploy and Host Trino on Railway

Trino is a distributed SQL query engine designed for fast analytics across multiple data sources. It lets you query databases, data lakes, object storage, and other systems using a single SQL interface without moving all data into one central database first.

## About Hosting Trino

Hosting Trino on Railway gives you a distributed query engine with one coordinator and multiple worker nodes.

This template uses a coordinator and three workers. The coordinator accepts queries, manages query planning, and schedules work, while the workers execute query tasks in parallel.

Trino does not act as the primary storage layer. Instead, it connects to external systems through catalogs and connectors, allowing you to query PostgreSQL, MySQL, Iceberg, Hive, Kafka, object storage, and many other supported data sources from one SQL engine.

The worker nodes communicate with the coordinator through Railway's private network, while only the coordinator needs to be exposed publicly.

## Common Use Cases

- Query multiple databases from a single SQL interface
- Run distributed analytics across large datasets
- Query data lakes and object storage
- Federate queries across PostgreSQL, MySQL, and other databases
- Analyze Parquet, Iceberg, Hive, and similar data lake formats
- Build analytical backends for BI and reporting tools
- Run cross-source joins without copying all data into one database
- Power data exploration and ad-hoc analytics
- Build lakehouse and federated data architectures
- Provide a shared SQL layer across heterogeneous data platforms

## Dependencies for Trino Hosting

- One Trino coordinator
- Three Trino worker nodes
- Railway private networking between cluster nodes
- External data sources connected through Trino catalogs
- Optional persistent storage for dynamically managed catalogs

## Trino Architecture

This template uses a four-node Trino cluster:

```text
Clients / BI Tools / Applications
              │
              ▼
      Trino Coordinator
              │
              │ Railway Private Network
        ┌─────┼─────┐
        ▼     ▼     ▼
    Worker 1 Worker 2 Worker 3
````

The coordinator is responsible for:

* Accepting SQL queries
* Parsing and planning queries
* Discovering available worker nodes
* Scheduling distributed query tasks
* Coordinating query execution
* Exposing the Trino Web UI

The workers are responsible for:

* Executing query tasks
* Reading data from connected catalogs
* Processing query splits in parallel
* Performing filtering, joins, aggregations, and transformations
* Returning partial results to the coordinator

Unlike a traditional database cluster, Trino workers are compute nodes and do not normally store the source-of-truth dataset themselves.

## Query Multiple Data Sources

One of Trino's strongest capabilities is federated querying.

Different systems can be exposed as catalogs and queried using the same SQL interface.

For example:

```sql
SELECT
    o.order_id,
    c.customer_name
FROM postgresql.sales.orders o
JOIN mysql.crm.customers c
    ON o.customer_id = c.customer_id;
```

This allows Trino to combine data from different platforms without first loading everything into a single database.

## Supported Workloads

Trino is commonly used with:

* PostgreSQL
* MySQL
* MariaDB
* Iceberg
* Hive
* Delta Lake
* Kafka
* MongoDB
* Elasticsearch
* Cassandra
* Object storage
* Data lake platforms

Additional systems can be connected through Trino's connector ecosystem.

## Trino vs Similar Platforms

| Feature                         | Trino | PostgreSQL | ClickHouse | DuckDB |
| ------------------------------- | ----: | ---------: | ---------: | -----: |
| Distributed query execution     |     ✅ |          ❌ |          ✅ |      ❌ |
| Federated queries               |     ✅ |         ⚠️ |         ⚠️ |     ⚠️ |
| Query multiple external systems |     ✅ |         ⚠️ |         ⚠️ |      ✅ |
| Data lake analytics             |     ✅ |          ❌ |          ✅ |      ✅ |
| OLAP workloads                  |     ✅ |         ⚠️ |          ✅ |      ✅ |
| Transactional database          |     ❌ |          ✅ |          ❌ |      ❌ |
| Stores primary application data |     ❌ |          ✅ |          ✅ |      ✅ |
| Horizontal compute scaling      |     ✅ |          ❌ |          ✅ |      ❌ |
| Cross-database joins            |     ✅ |         ⚠️ |         ⚠️ |      ✅ |
| Distributed SQL engine          |     ✅ |          ❌ |          ✅ |      ❌ |
| Suitable for BI workloads       |     ✅ |          ✅ |          ✅ |      ✅ |

Trino is particularly useful when data already exists across multiple systems and you want to query it through one distributed SQL layer.

PostgreSQL is more suitable for transactional application workloads, while ClickHouse is optimized for storing and querying large analytical datasets directly.

DuckDB is ideal for lightweight and embedded analytics, while Trino is better suited for distributed analytics across multiple remote data sources.

## Why Use Trino?

Trino separates compute from storage.

Instead of requiring all data to live inside Trino itself, queries are executed directly against connected systems. This makes it useful for modern architectures where data may already exist across databases, warehouses, data lakes, and object storage.

Trino can scale analytical compute independently by adding worker nodes, while the underlying data remains in its existing storage platform.

This architecture is especially useful for:

* Federated analytics
* Data lake queries
* Lakehouse architectures
* Cross-platform reporting
* Enterprise data platforms
* Large-scale SQL analytics

## Horizontal Scaling

Trino scales query execution by adding worker nodes.

More workers can provide:

* Higher query concurrency
* More parallel processing capacity
* Faster scans of large datasets
* Increased aggregate CPU and memory
* Better throughput for analytical workloads

The coordinator distributes query tasks across available workers and combines the results before returning them to the client.

Because workers are generally stateless compute nodes, scaling the Trino execution layer does not require redistributing the underlying source data.

## Why Deploy Trino on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Trino on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.


## Similar templates

- [Betterlytics](https://railway.com/deploy/betterlytics) — Betterlytics is a cookieless analytics platform GDPR-compliant.
- [Finance Tracker](https://railway.com/deploy/finance-tracker-1) — Private multi-user household finance ledger with budgets and CSV import.
- [Matomo Analytics + MariaDB](https://railway.com/deploy/matomo-analytics-mariadb) — Privacy-friendly analytics with MariaDB and persistent volumes.

Open this page in a browser: https://railway.com/deploy/trino