Before the REST specification, Iceberg 129 tables lived in catalogs built for other purposes, and many still do:
| Catalog | Pointer kept in | Strengths | Weaknesses |
|---|---|---|---|
| Hive 129 Metastore | HMS table property | Hadoop 129 estates; Hive 4.2 adds REST | JVM service, Thrift, locks |
| AWS Glue 24 Data Catalog | Glue table parameter | Managed, IAM; REST endpoint too | AWS 24 only, priced per object |
| JDBC (JdbcCatalog) | A row in a SQL database | Simple; the fixture uses it | No server: drivers everywhere |
Iceberg's HiveCatalog commits under a lock in the Hadoop-era metastore of Data Lakes and Swamps, and Hive 4.2 can serve the same tables over Iceberg REST, a migration path that moves no data. The JDBC catalog is a library, not a server, so permissions have no central home; the file-based Hadoop catalog needs atomic renames, which S3 lacks. The direction is clear: a REST server in front, whatever stores the pointers.