> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/build/v1/productize/connect-engine/trino/dedicated-trino.md).

# Dedicated Trino

Use this path when the Trino cluster should be part of the data product deployment itself. You don't manage the cluster separately from the product: a single vulcan trino resource provisions the coordinator and workers, generates catalogs from your depots or DataOS-provisioned secret catalogs, and runs the plan and run workflows.

This page covers the connection and deploy shape. For tuning, failure modes, and local development, see the [Trino engine manual](https://v2.dataos.info/references/engine-guide/trino-1/dedicated-cluster) in References.

## How it works

One vulcan trino resource creates 4 cooperating resource containers:

```
<name>-trino           Trino coordinator (replicas: 1)
<name>-trino-workers   Trino workers
<name>-plan            vulcan plan --auto-apply (waits for the cluster)
<name>-run             vulcan run (scheduled; depends on plan)
```

Check their status with:

```bash
dataos-ctl -t vulcan -n <name> get runtime
```

Vulcan generates catalogs automatically: one per depot in `deployment.depots[]`, plus one per secret catalog you define.

## Prerequisites

Request these from your platform team:

* A Trino-capable compute pool.
* The tenant-level `vulcan` stack installed.
* One depot per source you read. The first depot must be a writable lakehouse depot; it's the materialization target.
* Tenant secrets `vulcan-state-connection` (Postgres) and `vulcan-object-store-connection` (S3), and a git-sync secret for your repo.
* Python 3.10 locally for the Vulcan CLI.

Confirm your depots are visible with `dataos-ctl get depot`.

## Permissions

There are no Trino SQL grants to configure here: Vulcan connects to the internal coordinator over the Kubernetes network with `method: no-auth`. Access control lives entirely at each depot's underlying data source: whatever the depot's credentials permit there is what Trino can do through that catalog.

| Depot type   | Trino connector  | Permission guide                                                                                                                          |
| ------------ | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `lakehouse`  | `iceberg` (REST) | DataOS-native; no external grants                                                                                                         |
| `postgres`   | `postgresql`     | [Postgres minimum permissions](https://v2.dataos.info/references/resources/vulcan/roles-and-permissions/postgres-minimum-permissions)     |
| `snowflake`  | `snowflake`      | [Snowflake minimum permissions](https://v2.dataos.info/references/resources/vulcan/roles-and-permissions/snowflake-minimum-permissions)   |
| `bigquery`   | `bigquery`       | Governed by IAM roles on the depot's service account                                                                                      |
| `databricks` | `delta_lake`     | [Databricks minimum permissions](https://v2.dataos.info/references/resources/vulcan/roles-and-permissions/databricks-minimum-permissions) |
| `delta_lake` | `delta_lake`     | AWS IAM (S3 + Glue/Hive Metastore)                                                                                                        |

## config.yaml

The gateway catalog is templated from an environment variable the stack injects, so the same file works locally and in production:

```yaml
name: my-trino-dp
description: "Managed Trino data product."
gateways:
  default:
    connection:
      type: trino
default_gateway: default
model_defaults:
  dialect: trino
  start: <YYYY-MM-DD>
  cron: "@daily"
```

{% hint style="info" %}
**Tenant comes from the environment**

`tenant` isn't a `config.yaml` key. Set `DATAOS_TENANT_ID` in your shell for local runs; the platform injects it automatically in production. Vulcan refuses to load the project without it.
{% endhint %}

There's no separate deploy manifest to exclude from model discovery: cluster settings for this same product live under `deployment.trino:` in this file (see [The deploy configuration](#the-deploy-configuration) below), so you don't need an `ignore_patterns` entry for it. Use `ignore_patterns` only if you have other, unrelated files in the project that Vulcan shouldn't parse as models.

## Models: always use three-part names

Use fully-qualified `catalog.schema.name` for the model name and every source you read. The default catalog is the first secret catalog if any exist, otherwise the first depot. Unqualified names are a common source of materializing to the wrong place, so always spell out all 3 parts:

```sql
MODEL (
  name <lakehousedepot>.bronze.orders,
  kind FULL,
  grains (order_id),
  assertions (
    unique_values(columns := (order_id)),
    not_null(columns := (order_id, customer_id, order_date))
  )
);

SELECT order_id, customer_id, order_date, order_status
FROM <postgresdepot>.public.orders_ext;
```

## The deploy configuration

There's no separate manifest to hand-author for the Trino cluster. Coordinator and worker settings live under a `deployment.trino:` block, inside the same `config.yaml` you already have, alongside `deployment.repo`, `deployment.compute`, and the other keys every engine uses. See [References → Vulcan → Deployment](https://v2.dataos.info/references/resources/vulcan/deployment) for the full `deployment:` walkthrough; this section covers only the Trino-specific parts.

The fields you'll change most often are `deployment.depots` (order matters: the first one is the default catalog and write target), `deployment.trino.coordinator.resource`, and `deployment.trino.workers`:

```yaml
deployment:
  repo:
    url: <repo-url>
    base_dir: <path/to/project>
    secret_id: <tenant>:<git-sync-secret>
  compute: <trino-compute-pool>
  run_as_user: svc-user

  depots:
    - dataos://<lakehousedepot>?purpose=rw   # default catalog and write target
    - dataos://<postgresdepot>?purpose=rw    # source

  trino:
    catalog:
      config: [ "lakehouse.metastore=thrift" ]
    coordinator:
      resource:
        request: { cpu: "1", memory: 2Gi }
        limit:   { cpu: "2", memory: 4Gi }
    workers:
      replicas: 1
      resource:
        request: { cpu: "2", memory: 4Gi }
      autoscale:
        min_replicas: 1
        max_replicas: 3
        cpu_target: 70

  use:
    secrets:
      - { id: <tenant>:<git-sync-secret>, context_alias: gitsync }
    env_vars:
      - key: TRINO_CATALOG
        template: "<lakehousedepot>"
```

Size `coordinator.resource` and `workers.resource` to fit the compute pool; an undersized coordinator or worker limit is the most common deployment failure. `TRINO_CATALOG` must match a real catalog name.

{% hint style="warning" %}
**`deployment.trino` is engine-gated**

`deployment.trino` is only valid when the resolved `engine` is `trino` (derived from the gateway `connection.type`, as here, or from `model_defaults.dialect`). Setting it under any other engine fails validation at `vulcan create_deploy_yaml` time, before anything reaches DataOS.
{% endhint %}

## Apply and verify

Deploying a dedicated Trino product uses the same single flow as every other engine: render the manifest from `config.yaml` and apply it, no separate `dataos-ctl resource apply -f trino-deploy.yaml` step required.

```bash
vulcan create_deploy_yaml -o - | dataos-ctl resource apply --in -l   # lint first
vulcan create_deploy_yaml -o - | dataos-ctl resource apply --in      # then apply
dataos-ctl resource -t vulcan -n my-trino-dp get -r
```

Confirm the cluster is up by looking for `SERVER STARTED` in the coordinator logs. The [Trino engine manual](https://v2.dataos.info/references/engine-guide/trino-1/dedicated-cluster) covers common issues (workers out of memory, wrong-catalog materialization, schedules expiring silently) and their fixes.

With the cluster running, continue to [Assets](/build/v1/productize/assets.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/build/v1/productize/connect-engine/trino/dedicated-trino.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.