Compare ten Apache Iceberg platforms on REST catalog support, multi-engine writes, managed compaction, cross-engine governance, and on-prem reach.
By
Billy Allocca
Table of Contents
Best Apache Iceberg Platforms for Enterprise Data (2026)
Apache Iceberg is an open table format that many vendors implement, so the best Iceberg platform for enterprise data is the one that gives you an open REST catalog, several engines writing to the same tables, managed table maintenance, and governance that holds across engines and environments. This guide compares ten platforms on those four criteria.
Reach across systems is the gap those criteria close. In NexusOne's 2026 State of the Data Estate report, conducted by Enterprise Management Associates (EMA) in September 2026 (n=202) and commissioned by NexusOne, 38% of data and analytics decision-makers named access to data across systems without moving or copying it as one of the things their environment delivers least well, the most cited weakness on the list [1]. Among respondents who had been blocked from using data they already held (n=189), 32% said the data sat in systems their tooling could not reach [1]. The survey did not ask about Iceberg, but a shared table format behind an open catalog is one of the most direct architectural answers to that gap.
For how Iceberg won the format contest, from the Tabular acquisition to Iceberg v3 on Databricks, read the companion post on why Apache Iceberg is becoming the default storage format for enterprise AI. The decision covered here comes after that one: which platform runs your Iceberg tables.
Is There a Best Apache Iceberg Provider?
No vendor owns Iceberg, because the Apache Software Foundation maintains the specification and every platform in this guide implements the same one [2]. Apache Iceberg is a published specification for the metadata that tracks which Parquet, ORC, or Avro files make up a table, along with its schema, its partitioning, and its history of snapshots, the committed states of the table that readers query. A table that Spark writes to the specification is readable by Trino, Snowflake, BigQuery, or DuckDB without conversion.
What vendors sell is everything around the format. The catalog is the service that maps a table name to its current metadata file, and because every commit passes through it, the catalog decides who can write, which storage credentials an engine receives, and which policies apply. The Iceberg REST catalog is the specification's HTTP protocol for that service, so a client written against it can switch catalogs through configuration instead of code [3]. Apache Polaris, the REST catalog Snowflake open-sourced in 2024, graduated to an Apache top-level project on February 19, 2026 [4], and it now underpins Dremio's catalog and the catalog SAP has announced for SAP Business Data Cloud [5][6].
So the useful question is which platform runs the catalog, engines, maintenance, and policy in a way that keeps the format's openness intact across your estate. Two platforms can both claim Iceberg support while one lets several engines write governed tables in your own data center and the other exposes read-only metadata to outside engines in a single cloud.
What Four Criteria Decide an Iceberg Platform?
Four criteria separate Iceberg platforms: catalog openness, multi-engine writes, managed table maintenance, and governance that holds across engines. Where the platform can run is the multiplier, because it decides whether the first four cover your whole estate or only the part that sits in one cloud.
Maintenance needs its own vocabulary. Compaction rewrites many small data files into fewer large ones, snapshot expiration removes old table states and the files only they reference, and orphan file cleanup deletes files that no snapshot references at all. Streaming ingestion and agent workloads add many small commits, so tables that nobody compacts get slower and more expensive to scan every week. Credential vending is the catalog handing an engine short-lived storage credentials scoped to one table, so the engine never holds a standing key to the bucket. The lock-in surface is everything you would have to rebuild to leave a platform: usually the catalog, the access policies, and the maintenance jobs, since the Parquet files themselves stay portable.
Criterion | What to test in a proof of concept | What failure looks like |
|---|---|---|
Open REST catalog | Point Spark, Trino, and one engine from a different vendor at the catalog's REST endpoint; create, write, and read a table from each | Engines need vendor-specific connectors, and leaving requires a metadata migration |
Multi-engine writes | Commit writes from two engines to one table and check that readers see consistent snapshots | Outside engines are read-only, so the vendor's engine becomes the only writer |
Managed maintenance | Confirm compaction, snapshot expiration, and orphan cleanup run on tables that outside engines wrote | Maintenance covers only tables the vendor wrote; the rest degrade |
Cross-engine governance | Apply a column mask and a row filter, then query from an outside engine that received vended credentials | Policy binds only the vendor's engine, and an outside engine reads raw files |
On-prem and hybrid deployability | Run the same catalog and policy model on-premises, in a second cloud, and in an isolated network | The catalog exists in one cloud and cannot govern tables in a data center or sovereign region |
How Do Ten Iceberg Platforms Compare?
The ten platforms fall into three groups: cloud data platforms that added Iceberg catalogs (Databricks, Snowflake, Google, Microsoft), a cloud infrastructure service (AWS), and engines or stacks you can run where you choose (Dremio, Starburst, Cloudera, IBM watsonx.data, NexusOne). The matrix reflects vendor documentation retrieved in October 2026, and "check current documentation" marks capabilities that primary sources did not confirm.
Platform | REST catalog support | Multi-engine writes | Managed compaction | Cross-engine governance | On-prem and hybrid | Lock-in surface |
|---|---|---|---|---|---|---|
Databricks (Unity Catalog) | Yes, Unity Catalog Iceberg REST API [7] | External engines write managed Iceberg tables; foreign Iceberg tables are read-only [7] | Predictive Optimization; external clients cannot expire snapshots or remove orphan files [7][8] | Row filters and column masks for external engines in Beta [8] | Cloud service on AWS, Azure, and Google Cloud | Policy and credential vending live in Unity Catalog |
Snowflake (Horizon Catalog) | Yes, Horizon Catalog endpoint [9] | External writes to Snowflake-managed v2 and v3 tables GA since May 26, 2026 [10] | Automatic compaction by default on Snowflake-managed tables [11] | Policy-protected tables reachable; enforcement for external engines needs extra connector setup [9] | Cloud service; external path excludes non-AWS S3-compatible storage [9] | Snowflake roles and policies govern access |
Dremio (part of SAP) | Yes, Open Catalog built on Apache Polaris [5] | Any REST-compatible engine reads and writes [5] | Auto optimization and table cleanup [5] | Check current documentation | Self-managed on Kubernetes, including S3-compatible storage such as MinIO, or Dremio Cloud [5] | Polaris-based catalog is portable; roadmap now set by SAP [12] |
Starburst (Enterprise and Galaxy) | Connects to REST catalogs such as Polaris; check current documentation for an exposed endpoint [13] | Through a shared external REST catalog [13] | Scheduled jobs for compaction, snapshot expiration, and orphan files [14][15] | Policies apply to queries through Starburst; check current documentation for other engines | Enterprise is self-managed; Galaxy is SaaS [14][15] | Access rules live in Starburst |
AWS (S3 Tables and Glue) | Yes, Glue Iceberg REST endpoint [16] | Third-party engines through the Glue endpoint with Lake Formation grants [16] | Compaction and snapshot management on by default [17] | Documented external-engine path requires full table access [16] | AWS regions only | IAM and Lake Formation hold the policy |
Google (Lakehouse, formerly BigLake) | Yes, Lakehouse runtime catalog REST endpoint [18] | Read and write across BigQuery, Spark, Flink, and Trino in Preview [18] | Opt-in automatic management in Preview; BigQuery-managed tables compacted automatically [18][19] | BigQuery fine-grained controls; check current documentation for external engines [19] | Google Cloud only | Google IAM and BigQuery policy |
Cloudera | Yes, REST catalog embedded in Hive Metastore with vended credentials [20] | Shares tables with Databricks, Snowflake, and others; check current documentation for external writes [21] | Lakehouse Optimizer, on-premises since the 7.3.2 release [21] | Apache Ranger policies govern REST catalog access [20] | On-premises and public cloud [21] | Cloudera runtime and its shared security layer |
Microsoft Fabric (OneLake) | Read-only metadata REST surface [22] | Iceberg written into OneLake is virtualized as Delta; Delta tables exposed as Iceberg V2 metadata [23] | Check current documentation | Check current documentation | Microsoft cloud service | Delta is native; Iceberg is a translated view |
IBM watsonx.data | Yes, Metadata Service Iceberg REST API [24] | Built-in Presto and Spark; external Spark creates and writes tables through the Metadata Service [25][26] | Check current documentation | Check current documentation | SaaS or software on Red Hat OpenShift [25] | IBM metadata service and Presto engine |
NexusOne | Yes, Apache Gravitino Iceberg REST service that federates Hive, JDBC, and other REST catalogs [27] | Trino, Apache Spark, and Apache Kyuubi write the same tables | Compaction, snapshot expiration, and orphan cleanup run as platform tasks | One Keycloak and Apache Ranger policy model across Trino, Spark, Kyuubi, and S3 objects | Same deployment on-premises, in any cloud, hybrid, or air-gapped | Apache-licensed catalog, engines, and policy engine |
Databricks and Snowflake now offer two of the most complete write paths for outside engines, and if most of your analytics already run on one of them, its catalog is the shortest route to multi-engine Iceberg. Unity Catalog lets external engines create, read, and write managed Iceberg tables through its REST API and federates foreign Iceberg catalogs in AWS Glue, Hive Metastore, and Snowflake Horizon for discovery and governance [8]. Snowflake made external writes to its managed tables generally available on May 26, 2026, for both v2 and v3 tables [10]. The limits are specific. External Iceberg clients cannot run snapshot expiration or orphan cleanup on Unity Catalog tables [7], and Snowflake's external path does not support create-table-as-select, equality deletes, or Iceberg branches and tags [9]. In both cases the access policy for a table lives in one vendor's identity system.
AWS and Google treat Iceberg as a storage primitive. S3 Tables run compaction to 64 MB to 512 MB target files and expire snapshots by default [17], which makes them the lowest-effort choice for an estate that lives on AWS. Two details deserve a test before you commit: the documented path for third-party engines on the Glue REST endpoint grants credentials only when the role has full permissions on the table [16], so column-level control for an outside engine needs another layer, and S3 Tables snapshot management fails for any table that carries a user-defined tag or branch [17]. Google's Lakehouse (the product renamed from BigLake) exposes an Iceberg REST endpoint, with read and write interoperability across BigQuery, Spark, Flink, and Trino, and automatic table management, both in Preview as of October 2026 [18].
Microsoft Fabric reaches Iceberg through translation. OneLake writes virtual Iceberg metadata for Delta tables and virtual Delta metadata for Iceberg tables, but the conversion produces Iceberg V2 metadata only, takes 5 seconds to 2 minutes after each change, and fails on equality deletes [23], and its Iceberg REST surface supports metadata reads only [22]. That suits a Fabric-first estate that needs Snowflake or Spark to read its tables, and it fits poorly when Iceberg is meant to be your primary write format.
Dremio, Starburst, Cloudera, and IBM watsonx.data can all run outside a single hyperscaler, which matters when part of your estate sits in a data center. Dremio's Open Catalog accepts reads and writes from any REST-compatible engine and automates compaction and snapshot cleanup [5]. SAP completed its acquisition of Dremio on July 6, 2026, and has said Iceberg and Polaris will be the native foundation of SAP Business Data Cloud [12][6], so estates with little SAP data should ask how the self-managed product will evolve. Starburst pairs Trino with scheduled compaction, snapshot expiration, and orphan cleanup jobs in its self-managed Enterprise product [14] and uses external REST catalogs such as Polaris to share tables with other engines [13]. Cloudera keeps on-premises deployment at the center of its product: its REST catalog applies Apache Ranger policies and vends scoped credentials [20], and its Lakehouse Optimizer reached on-premises customers in the March 2026 Base 7.3.2 release [21]. IBM watsonx.data pairs Presto and Spark with a Metadata Service that external Spark clients use as an Iceberg REST catalog, and it ships as SaaS or as software on Red Hat OpenShift [25][26].
A self-assembled stack of an Apache catalog such as Polaris or Gravitino with Spark and Trino is the option outside the table. It keeps every control point in your hands and costs the integration and operations work these platforms exist to absorb, a trade-off the guide to running Iceberg on Kubernetes works through in detail.
Which Iceberg Setup Fits Single-Cloud, Multi-Cloud, and On-Prem Estates?
Match the platform to where your tables and engines will live over the next three years, because the catalog is the hardest component to replace once policies and maintenance depend on it.
Estate type | Strong fit | What to verify | Choose something else when |
|---|---|---|---|
Single cloud, one dominant engine | That cloud's or platform's managed Iceberg: Unity Catalog, Snowflake Horizon, S3 Tables, Google Lakehouse | Every client speaks the REST protocol, so the catalog can move later | A second cloud or a data center enters the roadmap |
Multi-cloud | A catalog that runs in each cloud and federates the others: Unity Catalog federation, Polaris-based catalogs, Apache Gravitino | Credential vending for every object store and one identity across clouds | Nearly all writes come from one platform, so its native catalog is simpler |
On-premises plus cloud | Stacks you can deploy yourself: Cloudera, Dremio, Starburst Enterprise, IBM watsonx.data, NexusOne | Maintenance and policy behave the same on-premises as in cloud | The on-premises footprint will be retired within a year |
Regulated or air-gapped | Catalog, engines, and policy that run inside your network with no vendor-hosted control plane | Whether any component calls a vendor service for licensing, metadata, or policy | Your regulator accepts a sovereign-region cloud service |
In a single cloud, the managed service usually wins on effort, and the protection you need is contractual and architectural: require the REST protocol from every reader and writer so that moving the catalog later is a configuration change [3]. In a multi-cloud estate, the catalog has to vend credentials for each object store and recognize one identity across clouds, or each cloud quietly becomes its own governance island. Hybrid estates add a harder test, because a capability that exists only in a vendor's cloud console cannot maintain or govern a table in your data center. The argument for keeping engines replaceable across all three shapes is laid out in the guide to zero lock-in compute and composable architecture.
When Is a Cloud Vendor's Managed Iceberg the Better Choice?
Managed Iceberg from your existing cloud or platform is the better choice when one engine does nearly all the writing, all of your data sits in that cloud, and no regulator asks where the catalog runs. In that estate, S3 Tables, Unity Catalog, Snowflake Horizon, or Google Lakehouse removes the compaction schedule, the catalog database, and the credential plumbing from your team's list, and the files remain readable by any compliant engine.
The cost shows up later and in governance rather than in storage. A managed catalog places access policy, credential vending, and maintenance inside one vendor's identity system, so an agent running in another cloud authenticates through that vendor and a deployment in your own data center cannot use the same catalog. Server-side scan planning, added to the REST catalog in Iceberg 1.11 [28], strengthens this pattern: Unity Catalog already uses it to return filtered scan plans so external engines read only authorized data [8], which improves consistency and also makes the catalog vendor the policy decision point for every engine you run. Plan for that dependency on purpose, and keep the exit open through the REST protocol.
What Does Iceberg v3 Change for Platform Choice?
Iceberg v3 makes engine support a platform criterion, because once a table is upgraded to v3 only engines that understand v3 can safely write it. The v3 specification adds binary deletion vectors, row lineage, a variant type for semi-structured data, default column values, geospatial and nanosecond timestamp types, and table encryption keys [2]. Iceberg 1.10, released in September 2025, closed the v3 specification and made deletion vectors production ready [29], and Iceberg 1.11, announced in May 2026, added server-side scan planning in the REST catalog and built-in table encryption [28].
Two v3 features change platform evaluations directly. A deletion vector is a compact bitmap per data file that marks deleted rows, which replaces piles of small positional delete files and keeps update-heavy tables fast without constant compaction. Row lineage assigns each row a stable identifier and a sequence number for its last change, which gives change data capture and audit a record of when every row changed. Both depend on every writer implementing them correctly, so a platform's v3 status matters as much as its catalog.
Platform or engine | Iceberg v3 status, October 2026 |
|---|---|
Databricks | Generally available across managed, foreign, and UniForm tables [8] |
Snowflake | External engines read and write v3 Snowflake-managed tables; they cannot upgrade a table from v2 to v3 [9] |
AWS | Deletion vectors and row lineage across EMR, Glue, and S3 Tables since November 26, 2025 [30] |
Trino | format_version 3 available and marked experimental [31] |
Microsoft OneLake | Produces and reads V2 metadata only [23] |
Others in this guide | Check current documentation |
Before you upgrade any table to v3:
List every engine that writes the table, including streaming jobs and notebooks.
Confirm each one supports v3 writes at the version you run.
Upgrade table by table, starting with tables a single engine writes.
Confirm your maintenance service handles deletion vectors and row lineage.
Keep v2 for tables that v2-only readers, such as OneLake, must consume.
How NexusOne Approaches Apache Iceberg
NexusOne runs the catalog, maintenance, and policy for Iceberg as one layer that deploys wherever your tables live, and the NexusOne AI Data Control Plane extends that layer to AI agents. Tables register in an Apache Gravitino catalog that exposes the Iceberg REST protocol, so outside engines connect to it the same way they would connect to Polaris or Glue [27], and Gravitino federates external catalogs such as Hive Metastore, JDBC catalogs, and other REST endpoints into one namespace. Trino, Apache Spark, and Apache Kyuubi run against the same tables. Identity enters once through Keycloak, federated from Active Directory, Okta, LDAP, or SAML, and policy is defined once in Apache Ranger and enforced across Trino, Spark, Kyuubi, and S3 object storage per object. Compaction, snapshot expiration, and orphan cleanup run as platform maintenance tasks instead of jobs your team schedules and monitors.
The deployment is identical on-premises, in any cloud, hybrid, or air-gapped, on a Kubernetes cluster you control, built from 85+ integrated open-source components with click-based upgrades and rollback. NexusOne's published deployment model is 5-5-5-5: about 5 minutes to provision, 5 hours to deploy, 5 days to the first governed workload, and 5 weeks to enterprise production, with Embedded Builders working alongside your team. A top-three US bank that had run three legacy Hadoop vendors connected 30 applications in under 4 weeks and eliminated more than $100 million in license and hardware costs. NexusOne estimates that assembling an equivalent open-source data layer yourself takes at least 18 to 24 months.
Agent and AI requests reach the same tables through the AI Data Control Plane, which screens requests for jailbreaks and PII at the edge, answers deterministic questions from the query engines at zero tokens, and logs allowed and blocked requests with reasoning; the guide to AI agent access control covers that enforcement pattern. If your estate is one cloud with one dominant engine and no on-premises footprint, that cloud's managed Iceberg is the simpler choice. If your tables span a data center and more than one cloud, book an expert consultation.
Key Takeaways
Apache Iceberg is one open specification, so the platform decision is about the catalog, engines, maintenance, and policy around it.
Test four criteria in a proof of concept: REST catalog access from outside engines, writes from more than one engine, maintenance on tables outside engines wrote, and masks and row filters that bind every engine.
Databricks and Snowflake now accept external writes to managed Iceberg tables, AWS and Google treat Iceberg as a managed storage primitive, and OneLake translates between Delta and Iceberg V2.
Cloudera, Dremio, Starburst Enterprise, IBM watsonx.data, and NexusOne can run outside a single cloud, which is the deciding factor for hybrid and regulated estates.
Upgrade to Iceberg v3 table by table, only after every writing engine supports it.
Whatever you choose, require the Iceberg REST protocol from every client so the catalog stays replaceable.
Frequently Asked Questions
What's the Best Apache Iceberg Open Table Format for Data Platforms?
Apache Iceberg is one open specification maintained by the Apache Software Foundation, so every compliant implementation writes the same format. The choice that matters is the platform around it. Pick one with a REST catalog, write access for several engines, managed compaction and snapshot expiration, and policies that bind every engine, then require the REST protocol from every client so the catalog stays replaceable.
Which Iceberg Open Table Format Provider Offers the Best Enterprise Data Platform Capabilities?
For an estate in one cloud, that cloud's managed Iceberg is strongest: Unity Catalog and Snowflake Horizon both accept writes from outside engines, and S3 Tables compacts automatically. For estates that include a data center, Cloudera, Dremio, Starburst Enterprise, IBM watsonx.data, and NexusOne deploy outside one cloud. Test external writes, maintenance on outside-written tables, and cross-engine masking before choosing.
What's the Best Iceberg-Based Lakehouse Platform for a Data Platform?
A data lakehouse runs warehouse-style SQL and AI workloads directly on open tables in object storage. The best Iceberg-based lakehouse is the one whose catalog, engines, and maintenance cover where your data actually lives. Databricks and Snowflake lead inside their clouds, AWS and Google offer managed Iceberg storage, and Cloudera, Dremio, and NexusOne run on-premises and in hybrid estates.
What's the Best Iceberg Open Table Format for Multi-Engine Analytics in a Data Platform?
Multi-engine analytics depends on the catalog more than the format. Choose a catalog that implements the Iceberg REST specification, accepts commits from Spark, Trino, Flink, and vendor engines, vends scoped storage credentials, and enforces masks and row filters for outside engines. Polaris-based catalogs, Unity Catalog, Snowflake Horizon, AWS Glue, and Apache Gravitino all implement the REST protocol, with different write and policy limits.
Should You Upgrade Iceberg Tables to v3 Now?
Upgrade a table to v3 once every engine that writes it supports v3. Databricks has v3 generally available, Snowflake reads and writes v3 managed tables from external engines, and AWS supports v3 deletion vectors and row lineage, but Trino marks v3 as experimental and OneLake writes only V2 metadata. Upgrade table by table, starting with tables that a single engine writes.
References
More Tools, Less Control: The 2026 State of the Data Estate Report, NexusOne, published September 30, 2026 (survey conducted by Enterprise Management Associates (EMA), September 2026, n=202 data and analytics decision-makers at organizations with 500+ employees in the US, Canada, the UK, and France). https://nexus0ne.substack.com/p/more-tools-less-control-the-2026 Retrieved October 20, 2026.
Iceberg Table Spec, Apache Iceberg (Apache Software Foundation). https://iceberg.apache.org/spec/ Retrieved October 20, 2026.
Apache Iceberg REST Catalog API (OpenAPI specification), Apache Iceberg. https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml Retrieved October 20, 2026.
Apache Polaris Graduates to Top-Level Project, Apache Polaris Blog, February 19, 2026. https://polaris.apache.org/blog/2026/02/19/apache-polaris-graduates-to-top-level-project/ Retrieved October 20, 2026.
Open Catalog Enterprise, Dremio Documentation. https://docs.dremio.com/current/data-sources/open-catalog/ Retrieved October 20, 2026.
SAP to Acquire Dremio to Unify SAP and Non-SAP Data to Power Agentic AI, Dremio Newsroom, May 4, 2026. https://www.dremio.com/newsroom/sap-to-acquire-dremio-to-unify-sap-and-non-sap-data-to-power-agentic-ai/ Retrieved October 20, 2026.
Access Databricks tables from Apache Iceberg clients, Databricks Documentation. https://docs.databricks.com/external-access/iceberg Retrieved October 20, 2026.
Advancing Apache Iceberg on Databricks: Iceberg v3 GA, Open Sharing, and Unified Governance, Databricks Blog, May 28, 2026. https://www.databricks.com/blog/unity-catalog-and-next-era-apache-icebergtm Retrieved October 20, 2026.
Access Apache Iceberg tables with an external engine through Snowflake Horizon Catalog, Snowflake Documentation. https://docs.snowflake.com/en/user-guide/tables-iceberg-query-using-external-query-engine-snowflake-horizon Retrieved October 20, 2026.
May 26, 2026: Apache Iceberg tables: Write support by using an external query engine (General availability), Snowflake Release Notes, May 26, 2026. https://docs.snowflake.com/en/release-notes/2026/other/2026-05-26-tables-iceberg-query-using-external-query-engine-snowflake-horizon-writes-ga Retrieved October 20, 2026.
Sep 22, 2025: Prevent data compaction on Snowflake-managed Apache Iceberg tables, Snowflake Release Notes, September 22, 2025. https://docs.snowflake.com/en/release-notes/2025/other/2025-09-22-enable-data-compaction-parameter Retrieved October 20, 2026.
SAP Completes Dremio Acquisition, SAP News Center, July 6, 2026. https://news.sap.com/2026/07/sap-completes-dremio-acquisition/ Retrieved October 20, 2026.
Apache Polaris introduction, Starburst Documentation. https://docs.starburst.io/introduction/polaris-intro.html Retrieved October 20, 2026.
Data maintenance, Starburst Enterprise Documentation. https://docs.starburst.io/latest/data-engineering/data-maintenance.html Retrieved October 20, 2026.
Iceberg Data Maintenance with Starburst, Starburst Blog, August 7, 2025. https://www.starburst.io/blog/iceberg-data-maintenance/ Retrieved October 20, 2026.
Accessing Amazon S3 tables using the AWS Glue Iceberg REST endpoint, Amazon S3 User Guide, AWS. https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-glue-endpoint.html Retrieved October 20, 2026.
Maintenance for tables, Amazon S3 User Guide, AWS. https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-maintenance.html Retrieved October 20, 2026.
Overview of Apache Iceberg tables, Lakehouse Documentation, Google Cloud. https://docs.cloud.google.com/lakehouse/docs/manage-tables Retrieved October 20, 2026.
Apache Iceberg managed tables, BigQuery Documentation, Google Cloud. https://docs.cloud.google.com/bigquery/docs/iceberg-tables Retrieved October 20, 2026.
Cloudera Iceberg REST Catalog overview, Cloudera Runtime 7.3.2 Documentation. https://docs.cloudera.com/runtime/7.3.2/overview/topics/cr-ds-cloudera-iceberg-rest-catalog.html Retrieved October 20, 2026.
Cloudera Base on premises 7.3.2 Release Summary, Cloudera, March 2026. https://docs.cloudera.com/cdp-private-cloud/latest/release-summaries/topics/announcement-202603-732.html Retrieved October 20, 2026.
Iceberg table APIs overview, Microsoft Fabric Documentation, Microsoft Learn. https://learn.microsoft.com/en-us/fabric/onelake/table-apis/iceberg-table-apis-overview Retrieved October 20, 2026.
Use Iceberg tables with OneLake, Microsoft Fabric Documentation, Microsoft Learn. https://learn.microsoft.com/en-us/fabric/onelake/onelake-iceberg-tables Retrieved October 20, 2026.
MDS Iceberg REST Catalog API, IBM watsonx.data API Documentation, IBM Cloud. https://cloud.ibm.com/apidocs/watsonxdata-ibm-mds-iceberg Retrieved October 20, 2026.
watsonx.data overview, IBM watsonx.data 2.0.x Documentation, IBM. https://www.ibm.com/docs/SSDZ38_2.0.x/lh-over/topics/overview.html Retrieved October 20, 2026.
Connecting Apache Spark to watsonx.data using the Iceberg REST Catalog, IBM Community, May 19, 2025. https://community.ibm.com/community/user/blogs/hemant-marve/2025/05/19/connecting-apache-spark-to-watsonxdata-using-the-i Retrieved October 20, 2026.
Iceberg REST catalog service, Apache Gravitino Documentation. https://gravitino.apache.org/docs/latest/iceberg-rest-service Retrieved October 20, 2026.
Announcing Apache Iceberg 1.11.0, Google Open Source Blog, May 27, 2026. https://opensource.googleblog.com/2026/05/announcing-apache-iceberg-1110.html Retrieved October 20, 2026.
Apache Iceberg 1.10: Maturing the V3 spec, the REST API and Google contributions, Google Open Source Blog, September 24, 2025. https://opensource.googleblog.com/2025/09/apache-iceberg-110-maturing-the-v3-spec-the-rest-api-and-google-contributions.html Retrieved October 20, 2026.
AWS announces support for Apache Iceberg V3 deletion vectors and row lineage, AWS, November 26, 2025. https://aws.amazon.com/about-aws/whats-new/2025/11/aws-apache-iceberg-v3-deletion-vectors-row-lineage Retrieved October 20, 2026.
Iceberg connector, Trino Documentation. https://trino.io/docs/current/connector/iceberg.html Retrieved October 20, 2026.
