This article provides a step by step comparison of the two Apache Iceberg REST catalog implementations AWS ships — AWS Glue and Amazon S3 Tables — measuring what each one actually serves.
A Python probe harness issues one identical request suite to both and stores the raw response as evidence. https://github.com/xbill9/lakehouse-iceberg-2026 AWS ships two Iceberg REST catalogs.
Both are managed, both are SigV4-signed, and both implement the same published specification.
If you are choosing between them, or writing a client that has to work against either, the interesting question is where they diverge.
They score identically and behave differently in thirteen places.
All results below were measured on 2026-09-03.
What Is the Iceberg REST Catalog?
An Iceberg table is a directory of Parquet files plus a chain of JSON metadata files recording which files belong to the table right now.
Something has to hold the pointer to the current metadata file, and make commits atomic by swapping it.
That is the catalog.
The REST catalog is one HTTP API for that job, so an engine needs one driver rather than one per catalog.
The specification lives in the Iceberg repository as and defines 35 operations.
This harness probes 25 of those 35, or 71%.
At This Point You Should Have An AWS account, and credentials with enough privilege to create a Glue database, an S3 bucket and an S3 Tables table bucket Python 3.13 with , and available for SigV4 signing Everything below was measured with account root, so no result here is a permissions artefact.
Where Are the Two Endpoints?
They are different services with different signing names.
AWS Glue Amazon S3 Tables Endpoint SigV4 signing name Warehouse the account id the table bucket ARN Signing Is Where the First Hour Goes SigV4 signs the exact query string, so the URL you sign must be the URL you send.
Building the URL and then letting an HTTP client re-encode the parameters separately produces a different canonical string: Build it once and send it whole. 's default is also wrong here, because SigV4 wants rather than .
With both fixed, the same request reaches the service and returns a real answer: A 403 signature error and a 404 no-such-bucket look equally like failure in a log.
Only one of them is about the catalog.
Bringing Up AWS Glue Glue rejects without an explicit table location: Every other catalog in this suite infers it from the warehouse.
Glue does not.
Bringing Up Amazon S3 Tables Two constraints surface only when you hit them.
Namespace names reject uppercase, which a timestamped scratch namespace will contain: And requires in the body: Seeding a table also failed against the managed bucket with 's default writer: Switching to worked.
Note the bucket name in that error is not the one you created — S3 Tables stores data in a managed bucket of its own.
The Prefixes Do Not Look Alike Every client reads the routing prefix from and puts it in every later URL.
The two services return very different shapes: Catalog Prefix as returned Glue S3 Tables Glue returns two path segments.
S3 Tables returns a percent-encoded ARN.
A client that assumes one segment, or that re-encodes what it was handed, produces URLs neither service routes.
The Scores Are Identical 🥈 AWS Glue 🥈 Amazon S3 Tables Read probes served 9/15 9/15 Write probes served 10/17 10/17 Not tested 1 1 fields present 26/30 27/30 Endpoints declared in none none Read and write surfaces are scored separately rather than summed, and probes whose prerequisite failed are excluded rather than counted as failures.
That table is the least interesting thing in this article.
The two implementations arrive at the same totals by different routes.
Neither One Tells You What It Supports The specification lets a server advertise its own surface: endpoints: A list of endpoints that the server supports. — , Five of the seven catalogs in the wider comparison publish that array.
Neither AWS catalog does: The field is optional, so this is not a specification vio