+1. again. I am not yet deeply familiar with the Polaris codebase or design. So apologies if I miss sth.
But directionally, supporting multiple table formats directly in the catalog is great and will help: a) Polaris also quickly support the emerging table formats b) Help engines adopt Polaris for these formats. Will turn Polaris into the clean HMS replacement we all want. In my opinion, doing 2 use-cases before generalizing will yield a solid long-term design. Once we implement two non-iceberg formats (delta, Hudi), it will be a good point to redesign, with support for even other formats. (Lance, Paimon, et al). Experiences from these two will help us. On 2025/06/14 05:47:41 Jean-Baptiste Onofré wrote: > Hi Rahil > > It's interesting, thanks for that. As a first step, the approach > corresponds to the one used for Delta. > > Long term, I would love to see support on other table formats directly > in the catalog (without the need of a fat client, I already mentioned > that while ago). > > So , +1 for now, but I still think we should consider no fat client in > the future. > > Regards > JB > > On Fri, Jun 13, 2025 at 5:32 PM Rahil C <rchert...@gmail.com> wrote: > > > > Hi all, > > > > I would like to start a discussion about adding support for Apache Hudi > > tables within Apache Polaris. > > > > I was able to look into the recent integration that was done for adding > > Delta as a Generic Table within Polaris > > <https://polaris.apache.org/in-dev/unreleased/polaris-spark-client/>, and > > believe that we can do an approach for Hudi that adds changes to the > > Polaris Spark Plugin that follows a similar pattern. > > > > I have put out an initial "draft" pr here, which more concretely > > demonstrates this integration: https://github.com/apache/polaris/pull/1862 > > > > Would appreciate thoughts/guidance from the community on how we can support > > this initiative. > > > > Regards, > > Rahil Chertara >
