8. Transformation Engine — Trino
Distributed SQL across heterogeneous sources. The federation engine, occasionally the transformation engine, rarely the ingestion engine.
Checked on 2026-09-25. There is no first-party managed Trino on GCP. The first-party route is the Trino optional component on Managed Service for Apache Spark clusters (Trino 432 on images 2.2/2.3, 480 on 3.0); the commercial routes are Starburst Galaxy and Starburst Enterprise on GCP Marketplace. Decide which one this module covers before writing it, and say so explicitly.
The role Trino plays
Interactive SQL over the lakehouse
MPP query engine designed for low-latency analytical SQL directly over object storage, with no data loading step.
Federation as the differentiator
One query spanning Iceberg tables, relational databases, and other sources. This, not raw throughput, is why clients ask for Trino.
Where it fits on GCP
The candidates are the Trino optional component on Managed Service for Apache Spark clusters, self-managed on GKE or Compute Engine, Starburst Enterprise (Marketplace, on GKE), or Starburst Galaxy (SaaS). None of Google's options is serverless, which is the main adoption obstacle in a GCP engagement.
Catalog compatibility
Read this against the same diagram in the other Chapter 3 modules — the frame is identical, so what changes is which pattern each engine is actually good at. Thick arrow: first-class read and write. Thin: works, with caveats. Dotted: read-only or degraded.
Trino's catalog ranking matches Spark's, but the fourth arrow is the one that decides engagements: no other engine on this list has it.
Lakehouse runtime catalog (Pattern 2)
The Iceberg connector against the REST catalog with iceberg.rest-catalog.security=GOOGLE. The natural pairing, with one catch: credential vending needs Trino 481 or later, and no Google cluster image ships that yet (checked on 2026-09-25) — so the component route means standing bucket access, or a self-managed/Starburst deployment. Google's and Trino's docs also show different endpoint versions (v1 versus v1beta) and property names; follow Google's.
Dataproc Metastore (Pattern 3)
The Hive Metastore catalog mode of the Iceberg connector, and the Hive connector for legacy non-Iceberg tables.
BigQuery-managed Iceberg (Pattern 1)
Read-only via exported metadata, or via the BigQuery connector — which pushes work back to BigQuery rather than reading the files.
The write path
What Trino supports
CREATE TABLE AS, INSERT, UPDATE, DELETE, TRUNCATE, and MERGE on Iceberg, with deletes written as position delete files. No branch or tag creation, and Iceberg v3 support is experimental. Real, but narrower and less battle-tested than Spark's.
Commit semantics
Same optimistic concurrency protocol; different retry and isolation configuration.
Maintenance procedures
optimize (bin-pack only), optimize_manifests, expire_snapshots, and remove_orphan_files exist as ALTER TABLE ... EXECUTE procedures. There is no sort or z-order compaction and no position-delete rewrite — Spark remains the better maintenance owner.
Performance and cost shape
The cost model
Cluster resource-time, running whether queried or not unless autoscaled. Very different from BigQuery's per-query pricing and from serverless Spark's per-batch billing.
Where Trino wins and loses
Wins on interactive latency and federation. Loses on the operational burden and on not being serverless in a platform where the alternative is.
No Aliz benchmark exists for Trino against these catalogs. Do not make comparative performance claims to a client without running one.
Governance
Trino's own model
System access control, file-based or Ranger/OPA-backed rules, catalog and schema level.
The integration problem
Trino's access control is a third, independent policy surface alongside BigQuery's and the catalog's. Three engines means three governance implementations to keep in agreement.
Development experience and orchestration
Client surface
ANSI SQL, JDBC/ODBC, and BI tool connectivity — usually the concrete reason a client wants Trino.
Orchestration
Trino as a step in an Airflow DAG, and where it fits relative to Spark ingestion and BigQuery serving.
When Trino is the right transformation engine
Decision gates
Cross-source federated queries are a genuine requirement; interactive latency over the lake matters; the client already runs Trino or a commercial distribution; or engine neutrality is a deliberate architectural goal.
Anti-patterns
Adopting Trino for BigQuery-shaped analytical SQL; using it as the primary ingestion writer where Spark is better supported; and adding it as a third engine without budgeting a third governance implementation.