Does Trino (Starburst distribution) officially support using Amazon FSx for Lustre (with S3 as the data repository) as the storage layer for Iceberg tables, instead of accessing the data and metadata directly via S3 APIs?
If this is not supported, is the limitation due to Trino’s architectural assumptions around object-store semantics and stateless workers, rather than Iceberg itself?
Additionally, are there any supported patterns where FSx for Lustre can be used alongside Trino + Iceberg (for example, read-only caching or Spark-based preprocessing), while keeping S3 as the authoritative Iceberg storage?
Neither FOSS Trino or COTS Starburst support using Amazon FSx for Lustre – they both access the metadata just like they do the data; via S3 APIs.
Trino/Starburst attack the metadata caching differently. As Iceberg connector — Trino 479 Documentation identifies, the Iceberg connector supports caching metadata in the coordinator memory. It also allows for file system caching of the metadata.
I’m not personally aware of the Iceberg specification requiring or preventing anything like this and most engines are doing some type of metadata caching their own way (likely very similar to Trino/Starburst).