Component reference
Trino — federation breadth
Engine-anchored architecture for multi-region, multi-platform SOCs that cannot, or should not, centralize all data into one store. Federate first, then query. Standard SQL throughout, so detection content stays portable.
Faster than the schema-on-read SIEM baseline (OpenSearch, 2.854s) on the same Zeek workload at 0.795s average query (single host, Tier B), with federation reach the schema-on-read SIEM tier doesn't offer. Iceberg, Postgres, cloud DWs, and Kafka queried in one SQL plane, without copying data into a central store.
The pipeline
Iceberg
Lakehouse
Long-term retention · hunting
Postgres / DWs
Operational stores
Snowflake, BigQuery, Postgres
Engine
Trino federation plane
Single SQL surface, all sources
Kafka
Streams
Near-real-time joins
Serve
SOC + analytics
Investigation, ad-hoc hunt
What composes, what’s brittle
- No central store required. Data stays where it sits; query reaches across.
- Why Trino. Mature connector ecosystem; standard SQL; horizontal scale-out.
- Best fit. Multi-region, data-residency, cross-jurisdiction SOCs.
- Trade-off. Slower than single-engine OLAP (0.795s vs. ClickHouse native 0.061s), and the highest join tax the SDW join bench measured: joined-over-flat ratio 4.35× on Trino where StarRocks and both ClickHouse arms sat near 1.8× (single host, Tier B).
- What survives. Standard SQL detections portable across engines.
- What's distinctive. Federation reach the schema-on-read SIEM tier doesn't offer.
Sources: Methodology: published spec, reproducible on equivalent hardware · Trino documentation