Hi Fluss community, I’d like to start a discussion about adding a native, read-only Trino connector for Apache Fluss.
There has already been previous exploration of Trino integration in FIP-18, #1810, PR #1923, and the related mailing-list discussion. Those efforts provide valuable prior work, but they also covered several relatively independent topics at once, including native Fluss reads, multi-version Trino support, Lakehouse Union Read, Lakehouse readers, and additional pushdowns. For this proposal, I’d like to narrow the scope and first establish a clean native Trino-to-Fluss read path. The initial scope includes: metadata discovery and type mapping; bounded reads of non-Lakehouse Log Tables; current-state reads of non-Lakehouse Primary Key Tables; projection and predicate-based scan optimizations; partition and bucket pruning where applicable; primary-key lookup optimization; an explicit Trino compatibility and build-isolation policy. Lakehouse Union Read, Lakehouse format readers, writes/DDL, and changes to Trino core are explicitly out of scope for this FIP. I think Union Read is an important follow-up topic, and I’d be happy to drive a separate proposal for it after the native connector is established. Since I don’t currently have permission to create the FIP page on Confluence, I’ve prepared the proposal as a Google Doc using FIP-XXX as the temporary identifier: Design doc: https://docs.google.com/document/d/1mY-PN8KY1cJSD9YzISuL14A6rEIH1Htj9l99XrLmPk0 Issue: https://github.com/apache/fluss/issues/4197 I’d especially appreciate feedback on the proposed scope, the Log Table and Primary Key Table read semantics, and the Fluss Client API boundary. Prior work: FIP-18: Fluss Trino Engine Support #1810 PR #1923 Feedback and suggestions are very welcome. Thanks, Shangqing
