Amazon Athena

Plain Parquet on S3 with Glue external tables: append and replace only. Opt into Iceberg tables through Glue to enable merge.

Every destination receives the same layout; see the tables Ingest creates.

Setup

Parquet in your S3 bucket, Iceberg metadata in your Glue catalog, queried by Athena. Ingest writes the table; you query it with the Athena you already have.

Grant access with a role: no redeploy on either side

The grant works exactly as for Amazon S3: create a role named IngestAccess-… in your account, trust your workspace's Ingest role with your workspace slug as the external id, and paste the ARN. Full trust-policy and permissions JSON is in that guide; the only difference here is what the permissions policy contains.

Glue and Athena permissions

Your IngestAccess-… role's permissions policy needs, beyond the S3 statements:

Glue: glue:CreateDatabase, glue:GetDatabase, glue:CreateTable, glue:GetTable, glue:UpdateTable, glue:DeleteTable, glue:GetTables, on the catalog, database and table resources for the databases Ingest creates.
Athena: athena:StartQueryExecution, athena:GetQueryExecution, athena:GetQueryResults on the workgroup, plus write access to that workgroup's query-results location.

One role carries all of it, because the run is one identity end to end; there is no separate "Glue credential" to keep aligned with the S3 one.

What to paste

S3 warehouse (s3://your-bucket/warehouse), the IAM role ARN, and AWS region. The region must match the bucket and the Glue catalog; a cross-region combination fails at the first query rather than at the connection test.

Then test it

Test connection creates a scratch schema and a table, writes a few rows through the same load path a real run uses, reads them back to check the count is exactly right, round-trips pipeline state, and drops the lot. It exercises the Glue database, the table, and the S3 write, so a bucket policy that grants ListBucket but not PutObject is caught here rather than on your first run.

Staging

needs_staging: s3. Staging always happens in the destination's own cloud and region; data does not take a detour through ours.

Conformance

Every adapter passes the same suite before it ships: create a table with every canonical type, append 100k rows, atomic replace, merge (latest dedup_sort wins; child tables delete-then-insert by root id), schema evolution, NULL-key rejection, package replay without duplicates, state and schema round-trip, row-count read-back, identifier edge cases, double-underscored table names (__quarantine, child tables), and rollback on a mid-load failure.