Iceberg on AWS Glue

catalog.default.table

The middle part is always the literal default. It is virtual: the catalog owns one Glue database named after itself, and default stands in for it. Writing the Glue database name there is an error.

Creating one

The only input is the catalog name. Thunderduck creates the Glue database for you — named after the catalog — and points it at a prefix inside the warehouse bucket. There is no credential to supply: access uses the platform's own role.

-- catalog "lake" owns Glue database "lake"
SELECT * FROM lake.default.events LIMIT 10;

Writing tables

CREATE TABLE … AS SELECT works and produces a real Iceberg table:

CREATE TABLE lake.default.orders_daily AS
SELECT date_trunc('day', created_at) AS day, count(*) AS orders
FROM   sales_pg.public.orders
GROUP  BY 1;

You do not need to supply a location. Glue requires every table to have one and does not inherit the database's, so Thunderduck derives one under the catalog's own prefix and injects it. A location you write by hand is honoured only if it sits inside that prefix — anything else is refused, because a table pointing at another tenant's prefix is a data leak, not a preference.

What lives where

Each catalog gets its own prefix, so two catalogs never share files:

s3://<warehouse>/<company>/<catalog>/<table>/

Shared catalogs have no company segment.

Limits worth knowing

• DROP TABLE against Glue is not currently reliable; remove tables in Glue.
• Table names are case-insensitive in practice — DuckDB lowercases quoted identifiers, so "Orders" and orders are the same table.

For the plain-DuckDB version of this setup (extensions, ATTACH, IAM and the table-location workaround), see DuckDB + Apache Iceberg on AWS Glue.