> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Iceberg

## Overview

Stigg's integration with Apache Iceberg allows you to export your product catalog, customer, and subscription data as Iceberg tables, backed by a catalog of your choice, for use with Spark, Athena, Snowflake, and other query engines.

<Note>
  Stigg's native data export integrations are included in the Scale plan, and are also available as an optional add-on to the Growth plan. See Stigg's pricing for more details.
</Note>

<Note>
  Apache Iceberg is currently a beta destination with an upper limit of 1 billion rows per month. [Contact Stigg support](mailto:support@stigg.io) if you expect to exceed that volume.
</Note>

<Card title="View the full entity schema" icon="sitemap" href="./schema">
  See every table and column exported to your destination, organized by entity group.
</Card>

## Setting up the integration

Iceberg requires a catalog to manage table metadata and provide atomic transactions. Stigg supports connecting via an **AWS Glue Catalog**, an **AWS S3 Tables Catalog**, an **Iceberg REST Catalog** (such as Cloudflare R2 Data Catalog or Tabular), or a **Google Lakehouse Catalog** (BigLake).

### Prerequisites

* An S3 bucket for the underlying data files
* An AWS Glue Data Catalog database

<Note>
  This guide covers **AWS Glue Catalog** as the primary flow, since it's the most common Iceberg catalog. If you use a different catalog, see [Other catalogs](#other-catalogs) below instead.
</Note>

<Steps>
  <Step title="Create the destination S3 bucket">
    In the AWS S3 console, click **Create bucket**. Enter a **Bucket name**. AWS recommends setting **Object Ownership** to **ACLs disabled** and **Block Public Access settings for this bucket** to **Block all public access**.

    Click **Create bucket**, and note the bucket name and AWS Region.
  </Step>

  <Step title="Create an IAM policy and role">
    In the AWS IAM console, create a policy that grants the following permissions, replacing `BUCKET_NAME`, `ACCOUNT_ID`, and `DATABASE` with your values:

    | Service   | Actions                                                                                                                                                                             |
    | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | AWS Glue  | `glue:GetDatabases`, `glue:GetDatabase`, `glue:GetTables`, `glue:GetTable`, `glue:GetPartitions`, `glue:CreateTable`, `glue:CreateDatabase`, `glue:UpdateTable`, `glue:DeleteTable` |
    | Amazon S3 | `s3:PutObject`, `s3:ListBucket`, `s3:GetBucketLocation`, `s3:GetObject`, `s3:DeleteObject`                                                                                          |

    <Note>
      If your bucket uses KMS encryption (CMK), also grant `kms:GenerateDataKey` and `kms:Decrypt` on the key.
    </Note>

    Create a role with a **Custom trust policy**, pasting in the trust policy shown in the Stigg connect form to allow `AssumeRole` access. Attach the policy above, then note the role's **ARN**.
  </Step>

  <Step title="Connect Stigg with Iceberg">
    In [Stigg](https://app.stigg.io/), navigate to **Integrations > Apps > Iceberg**.

    Enter the following information in the connection form:

    | Field              | Description                                |
    | ------------------ | ------------------------------------------ |
    | Bucket name        | The name of your S3 bucket                 |
    | Bucket region      | The AWS region where the bucket is located |
    | Role ARN           | The ARN of the IAM role created above      |
    | Glue database name | The name of the target Glue database       |

    Click **Test & connect**.
  </Step>

  <Step title="Select entities to export">
    After entering your connection details, expand the **Entities to export** section to choose which entity groups to include in the sync. All groups are selected by default.

    See [Exported entities](./overview#exported-entities) for a description of each group.
  </Step>
</Steps>

## Other catalogs

Once connected via any of these catalogs, finish by clicking **Test & connect**, then expand **Entities to export** on the connect form — see [Exported entities](./overview#exported-entities) for a description of each group.

### AWS S3 Tables Catalog

This catalog requires two S3 buckets: an **S3 Tables bucket** for the catalog itself, and a standard **staging S3 bucket** in the same region.

The IAM role's trust policy must allow the role to assume itself, in addition to the usual service principal — the role has to be created first, then its trust policy updated afterward, since it can't be self-assuming at creation time.

<Warning>
  IAM changes can take 5-10 minutes or longer to propagate. If the connection fails immediately after granting access, wait and retry.
</Warning>

Connection fields:

| Field                        | Description                                                                  |
| ---------------------------- | ---------------------------------------------------------------------------- |
| S3 Tables bucket ARN         | The ARN of your S3 Tables bucket                                             |
| Destination S3 bucket name   | The staging bucket's name                                                    |
| Destination S3 bucket region | The staging bucket's AWS region                                              |
| Role ARN                     | The ARN of the IAM role, granted both catalog and staging-bucket permissions |
| Namespace                    | The S3 Tables namespace to sync into                                         |

### Iceberg REST Catalog

**Cloudflare R2 Data Catalog** — benefits from zero egress fees. Create an R2 bucket and an API token with **Admin Read & Write** permissions in the Cloudflare dashboard, then provide:

| Field                | Description                                                                   |
| -------------------- | ----------------------------------------------------------------------------- |
| Catalog URI          | `https://api.cloudflare.com/client/v4/accounts/YOUR_R2_ACCOUNT_ID/r2/catalog` |
| API Token            | The R2 API token created above                                                |
| Bucket name          | Your R2 bucket name                                                           |
| Region               | Your R2 bucket region                                                         |
| R2 access key ID     | An R2 access key ID                                                           |
| R2 secret access key | The corresponding secret access key                                           |

<Warning>
  The catalog path must start with `__r2_data_catalog`.
</Warning>

**Tabular** — create a credential with table-creation and write-data permissions in your Tabular organization dashboard, then provide:

| Field         | Description                            |
| ------------- | -------------------------------------- |
| Catalog URI   | `https://api.tabular.io/ws`            |
| Client ID     | The Tabular credential's client ID     |
| Client secret | The Tabular credential's client secret |

### Google Lakehouse Catalog (BigLake)

Requires a GCP service account with GCS read/write and Lakehouse catalog management permissions, granted either via impersonation (recommended — grant **Service Account Token Creator**) or a service account key. Your Lakehouse catalog must be configured to use **end-user credentials**, not credential vending.

Grant the service account **Storage Object Admin** on the destination bucket and **BigLake Editor** on the target project/catalog (or the equivalent fine-grained `storage.*` and `biglake.*` permissions).

| Field                   | Description                              |
| ----------------------- | ---------------------------------------- |
| Google Cloud Project ID | Your GCP project ID                      |
| Catalog name            | The BigLake catalog name                 |
| Schema                  | The schema/database within the catalog   |
| Bucket name             | The GCS bucket backing the catalog       |
| Service account email   | The service account granted access above |

<Note>
  BigLake tables are queryable directly in BigQuery without needing an external table definition.
</Note>

## Configuration options

Data is staged under a `_write_ahead_staging` prefix before being atomically committed into the final table. We recommend configuring an object storage lifecycle policy to delete objects under that prefix after 30 days.

**`retention_window_days`** sets how long historical snapshots are retained — configure it according to your organization's data retention policy.

<Warning>
  Changing these settings on an existing destination table won't take effect until you perform a full refresh of the table.
</Warning>

<Note>
  Treat destination tables as read-only. Executing write or delete operations against them manually may corrupt the table state. Snapshot expiry and compaction are handled automatically — no manual maintenance is required, though delete permissions are still needed for this background maintenance to run.
</Note>


## Related topics

- [Exported entities](/documentation/importing-and-exporting-data/export/overview#exported-entities.md)
- [Sync process, schedule, manual sync, and sync history](/documentation/importing-and-exporting-data/export/overview#sync-process.md)