Hi Talat, Thank you for sharing the Iceberg use case. This is exactly where we would like to get with this FLIP: make GEOGRAPHY available as a native Flink SQL / Table API type so that Iceberg GEOGRAPHY columns can be used directly from Flink.
To show how a Flink-native GEOGRAPHY type could be implemented, we started prototyping it [1][2]. These draft PRs introduce the native Flink GEOGRAPHY logical type model and the initial Java Table API / runtime representation pieces. Native Calcite support could be considered as a possible follow-up. Making Calcite support a prerequisite, however, would add another upstream release path before Flink users can use GEOGRAPHY. Recent Calcite upgrades in Flink show that this can take many months, and in some cases more than a year, which would be a long wait for the Iceberg GEOGRAPHY use case. We would appreciate feedback from Flink committers / PMC members on these prototype PRs, especially on whether the proposed type-system shape and implementation boundaries look reasonable for the FLIP discussion. That feedback would help us refine the proposal and prepare the next step in the process. Best regards, David [1] https://github.com/apache/flink/pull/28679 [2] https://github.com/apache/flink/pull/28680 On Mon, Jul 6, 2026 at 11:03 PM Talat Uyarer <[email protected]> wrote: > Hi David, Ramin, Sergey, > > I would like to express strong support for this FLIP! I am writing to you > as an Apache Iceberg contributor. :) > > In the Iceberg community, we are highly anticipating first-class > geospatial support in Flink. With Apache Iceberg v3, the table > specification now natively supports GEOGRAPHY spatial types (backed by > WKB). For Flink users to seamlessly read, write, and query these tables, > having native GEOGRAPHY support in Flink SQL and the Table API is a crucial > prerequisite. We are eager to leverage this FLIP to implement Iceberg's Geo > Type support on Flink. > > Regarding the implementation path, while aligning with Calcite is a great > long-term goal, making a Calcite-first implementation a hard blocker will > significantly delay this FLIP. The process of introducing the type in > Calcite, waiting for a Calcite release, and then upgrading Calcite in Flink > is historically a 1-to-2 year journey. We saw similar situation with Flink > variant support. At that time Calcite was supporting Variant. In this case > There is no type in Calcite also. > > Ramin and Sergey, what do you think about Flink introducing GEOGRAPHY as a > native logical type (backed by WKB) within its own type system first? This > would unblock the Iceberg-Flink integration immediately, while the > community can explore upstreaming or refactoring toward Calcite as a > secondary, non-blocking phase. > > I believe implementing this natively within Flink first is the most > pragmatic way to deliver value to the community quickly without stalling > ecosystem integrations. Thank you again, David, for initiating this FLIP. I > look forward to contributing to and supporting this effort from the Iceberg > side! > > Best regards, > > Talat > Apache Iceberg Contributor >
