Trino

Solution

Nothing durable of yours. Coordinator + workers query catalogs. Gold tables live in Iceberg, Hive, or a warehouse. Calling Trino a warehouse is a fail.

Solution

A federated connector without pushdown and a dashboard SELECT *. Point Trino at a replica, or do not point it at OLTP. This is the classic Trino incident.

Solution

Trino for interactive federation. Spark for heavy ETL. Same table, different engines — that is the lakehouse pitch. Two writers is still forbidden.

Solution

Workers shuffle the world. Column prune in the SQL and in the file format. Trino is not magic; it is a distributed scan.

Solution

When you need a stable SLA, cost attribution, or joins that hammer three systems. Land a table. Federation is for exploration and for sources you refuse to copy — not for the 9:00 exec dashboard.

Solution

It stores the query engine’s metadata/catalog config and the plan. The data lives in Iceberg/Hive/Postgres. People page you because a federated scan of prod Postgres looked like a warehouse.

Solution

Do not federate large facts against primary. Replicate dims to the lake, or restrict the catalog, or cap query memory and scan size. Federation is for small lookups, not the 09:00 dashboard.

Solution

It still reads every column from Parquet footers/row groups you need — column pruning helps only if you list columns. Teach BI to select metrics. SELECT * is a cost bug.

Solution

Iceberg snapshots and optimistic commit; Hive table is files + a metastore that races. Two writers on Hive is corrupt partitions. Iceberg is the contract.

Solution

Stats missing or stale on Iceberg, so NDV looked tiny. ANALYZE / snapshot stats, or hint, or raise the broadcast threshold only with a story. Hints without stats are superstition.

Solution

Heavy shuffles, iterative ML, and huge writes with custom committers. Trino shines at interactive SQL on the lake. Spark shines at jobs. Do not run nightly 8-hour ETL only in Trino because “SQL is simpler” if the plan is a disaster.