We also discussed this topic in the last 2 catalog syncs. There are questions about whether batch load is the right solution for catalog federation use case. Instead, people think the events endpoint can still work reasonably well with just-in-time refresh, even without a strong 100% guarantee on event delivery. Even though we may not use batch load for the incremental refresh, it can still be useful for the initial sync or full reconciliation. Support remains for the other use cases that the batch endpoint enables. This thread also contains positive feedback for this feature.
I created a REST spec PR to make the concrete proposal easier to see. https://github.com/apache/iceberg/pull/15528 The universal load endpoint has come up in this discussion and some other discussions (like MV, index). I want to clarify that this is outside the scope of this batch load proposal and can be tackled separately. The universal load endpoint applies to both single load and batch load points. On Wed, Feb 4, 2026 at 2:29 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi > > I took a quick look at the document. > > Generally speaking, it makes sense to me. > > I have some questions about a few details: > - I believe that the batch load endpoint will be probably "polymorphic": > this endpoint will probably have slightly different behaviors depending on > the client/use case. I would explore the idea of having a header param to > define endpoint behavior. > - The response (depending on the previous point) should probably clearly > specify via error codes. > > I will comment directly in the document. I'm happy to help on this one. > > Thanks, > Regards > JB > > On Mon, Feb 2, 2026 at 7:04 PM Steven Wu <[email protected]> wrote: > >> Hi, >> >> I would like to discuss a proposal to add batch load endpoints for tables >> and views to the REST spec. >> >> https://docs.google.com/document/d/1VW5hgaaajRWtp5KbOU3s83YyoyPi5WOSvHtoJ_yXzJs/edit?tab=t.0 >> >> It can help with the use cases >> * Catalog federation: improve refresh throughput and reduce load on the >> source catalog >> * Improve planning performance by loading multiple referenced tables in >> one request. >> * Improve MV freshness evaluation if referencing multiple source tables >> >> Thanks, >> Steven >> >
