Hi all, Something we've been hearing from customers is that getting rows into Iceberg tables is still harder than it should be. The REST Catalog has done a great job standardizing how clients manage tables and commit snapshots, but the actual "send me some rows" part is left to each implementation to figure out independently.
Right now, customers either run a full compute engine to write Parquet and commit, or they use whatever proprietary ingestion API their catalog vendor offers. Both work, but neither is portable across catalogs the way the REST Catalog made metadata operations portable. We've been thinking about whether there's a natural place for this in the REST Catalog spec — something like a rows endpoint on a table that accepts JSON or Arrow, validates against the schema, and lets the catalog handle the rest. Not sure if this is the right level of abstraction for the spec or if it's better left to implementations, but wanted to see if others in the community have been thinking about this too. Would love to hear if anyone else is seeing the same gap, or if there are reasons this doesn't belong in the spec. Gokul
