Amazon S3 Tables Movie Catalog Demo

Amazon S3 Tables Movie Catalog Demo is a Next.js application that compares movie-catalog snapshots stored as an Apache Iceberg table in Amazon S3 Tables, connecting securely through Vercel OIDC Federation without hardcoded access tokens. It is published by Vercel and deploys with one click that clones the repo, creates a Vercel project, sets up the AWS integration, and provisions a new S3 Tables table bucket.

What is Amazon S3 Tables Movie Catalog Demo?

The demo is a single-page catalog snapshot experience built on Next.js App Router and deployed on Vercel. It takes a table bucket provisioned by the Vercel AWS integration as input and produces three preset views over the catalog.movie_catalog_snapshots Iceberg table: catalog changes, license exposure, and metadata quality. Reads and writes go through DuckDB against the S3 Tables Iceberg REST endpoint.

Key Features

• Two-client architecture — @aws-sdk/client-s3tables handles namespace and table management, while DuckDB with the Iceberg extension handles row reads and writes, since the AWS SDK has no row-level API.
• Snapshot diffing — the catalog changes view derives Added, Removed, and Licence renewed by FULL OUTER JOIN on the two most recent snapshots rather than reading a status column.
• Three preset queries — catalog changes (two most recent snapshots), license exposure (rights ending within 90 days), and metadata quality (incomplete metadata in the current snapshot).
• 60-second read cache — a cache hit never opens DuckDB, keeping the native binding and Iceberg extension off the request path.
• Server actions for snapshot control — "Append next snapshot" and "Reset to baseline" drive deterministic derivation, capped at six snapshots.
• Idempotent provisioning — npm run db:setup creates the namespace and table if absent and seeds baseline snapshots if the table is empty, run on every build via vercel.json.
• Safe status endpoint — GET /api/status reports missing variables but never returns account IDs, role ARNs, resource ARNs, or bucket names.
• CLI parity — db:check, db:append, db:migrate, and db:seed mirror the UI operations.

Who is it for?

• Next.js developers evaluating S3 Tables: deploy the demo to see an Iceberg table provisioned, seeded, and queried end to end without managing Parquet files or table metadata.
• AWS architects testing OIDC federation: inspect how server-side S3 Tables access works without hardcoded access tokens.
• Data engineers exploring Iceberg clients: use the DuckDB ATTACH ... (TYPE ICEBERG, ENDPOINT_TYPE 'S3_Tables') pattern as a starting point for row-level access.

How does it work?

Clicking Deploy clones the repository and provisions the table bucket through the Vercel AWS integration. Locally, vercel env pull fetches credentials, npm run db:setup creates and seeds the table, and npm run dev serves the app at localhost:3000. Because DuckDB ships a native binding per platform, next.config.ts keeps it out of the bundle and traces the binding into every querying route.

FAQ

Does the demo need hardcoded AWS access tokens?

No. It uses Vercel OIDC Federation to obtain credentials, and all S3 Tables access happens server-side, so no table identifier or credential is exposed to Client Components.

How do I reset the catalog table?

There is no in-place reset because DuckDB's Iceberg support implements neither DELETE nor snapshot rollback. The reset control drops and rebuilds the table, and the manual equivalent is aws s3tables delete-table followed by npm run db:setup.

How many snapshots can I append?

Appending stops at six snapshots; reset to baseline returns the catalog to its two starting snapshots and lets you continue.