A comprehensive comparison of Apache Iceberg catalog options in mid-2026: Apache Polaris (now an ASF Top-Level Project), Snowflake Open Catalog (soft-sunset for new signups), Snowflake Horizon Catalog (now Snowflake's recommended catalog, absorbing both governance and Iceberg REST catalog duties), AWS Glue Data Catalog (with documented REST API gaps like no UpdateTable, no v3 table creation, no credential vending), and Project Nessie (being merged into and eventually retired in favor of Polaris). The piece argues the catalog landscape is consolidating around the Iceberg REST spec rather than fragmenting, highlights credential vending as the key differentiator, and offers a decision framework based on where an organization's governance perimeter lives, plus a real-world federated multi-catalog architecture pattern.
Questions this post answers
Should new customers use Snowflake Open Catalog or Horizon Catalog for Iceberg tables in 2026?
Horizon Catalog is now Snowflake's recommended option for new customers, not Open Catalog. Snowflake has closed new signups for Open Catalog, meaning accounts that never created one cannot sign up for a first one, though existing Open Catalog customers can keep using and creating more. Horizon now speaks Iceberg REST outward while also serving as the full governance layer, effectively absorbing Open Catalog's interoperability role. Teams choosing between Snowflake catalog options can track these shifts as they weigh lakehouse architecture on daily.dev.
What are the limitations of using AWS Glue as an Iceberg REST catalog for multi-engine access?
Glue's Iceberg REST endpoint does not support UpdateTable, cannot create Iceberg v3 tables (only v1 and v2 via CreateTable), does not vend credentials so every engine needs its own IAM credentials, and each Glue catalog is regional requiring extra configuration for cross-region access. These gaps are mostly invisible for AWS-only workloads but become friction once non-AWS engines or v3 tables are involved. Engineers evaluating Glue against credential-vending catalogs like Polaris can weigh these trade-offs on daily.dev.
Is Project Nessie being discontinued in favor of Apache Polaris?
Yes, Dremio has publicly committed to merging Nessie's catalog-level versioning, multi-table transactions, and Git-for-data branching semantics into Apache Polaris, and plans to retire standalone Nessie once read/write parity is reached. Choosing Nessie is therefore increasingly a way to adopt Polaris-with-branching early rather than a bet on a permanently separate product. Anyone planning a data CI/CD workflow around Nessie can follow this migration path on daily.dev before committing.