AWS added Variant data type support to Amazon S3 Tables on July 28, letting teams write JSON without a predefined schema and still get efficient analytical query performance through Apache Iceberg V3 features like file pruning and automatic compaction.
Back to NewsAWS added Variant data type support to Amazon S3 Tables on July 28, 2026. The feature follows the Apache Iceberg Version 3 (V3) specification and is live in 15 AWS regions.
For data platform and analytics teams managing lakehouse environments, you can now write semi-structured data like JSON directly to S3 Tables without defining a fixed schema in advance. AWS says this lets teams land data faster while still getting efficient analytical query performance.
When an Iceberg V3-compatible engine writes Variant data, it shreds the semi-structured content into hidden columns. That shredding generates Parquet column statistics that query engines use for optimizations like file pruning, which reduces how much data a query must scan. Schemaless writes do not require trading away analytical efficiency.
S3 Tables also provide ongoing table maintenance, including compaction, for Variant columns. Compaction consolidates small files into larger files that Iceberg engines can read more efficiently.
S3 Tables work with any Iceberg-compatible engine, including Apache Spark, Trino, Amazon Athena, Amazon Redshift, and other third-party tools. Variant, however, is an Iceberg V3 feature. The AWS Prescriptive Guidance is direct: verify that all engines accessing the table support version 3 before upgrading or creating V3 tables.
The compatibility picture is uneven. Amazon Athena (Trino) does not support version 3. Amazon EMR for Apache Spark requires EMR release 7.12 or later. AWS Glue and Amazon SageMaker Unified Studio notebooks support version 3.
The compatibility check is not optional. An engine without Iceberg V3 support will fail with a format-version error when it reads a V3 table.
Teams considering an upgrade from existing Iceberg V2 tables face one hard constraint. Version 3 is a one-way upgrade. After a table is upgraded from version 2 to version 3, it cannot be downgraded back to version 2 through standard operations. AWS guidance recommends testing in a non-production environment first before committing production tables.
New tables created directly as V3 do not face this constraint. To create a new Iceberg version 3 table, set the format-version table property to 3. That approach sidesteps the upgrade path and reduces migration risk for new semi-structured workloads.
Variant support is live in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), and South America (São Paulo).
Teams with workloads outside this list should check AWS documentation before building pipelines that depend on this feature. The announcement does not state a timeline for additional regions.
For data platform, analytics, and cloud architecture leaders, the decision has a bounded scope.
Engine compatibility audit. List every engine that reads or writes the target tables. Confirm each one supports Iceberg V3. If Amazon Athena is in your query path, the AWS compatibility table lists it as not supporting version 3 at this time.
Regional coverage check. Confirm your primary and any secondary AWS regions appear in the 15 supported.
Upgrade path decision. Decide whether to create new V3 tables for semi-structured workloads or upgrade existing V2 tables. The one-way upgrade constraint changes that risk profile materially. New tables created directly as V3 carry none of that constraint.
Governance review. Schemaless ingestion may shift governance burden downstream. Column statistics generated during shredding help query engines, but your data catalog, access policies, and data quality checks may need updates to account for Variant columns. Neither the announcement nor the AWS Prescriptive Guidance describes how existing catalog integrations handle Variant column metadata, so treat that as an open item until you verify it in your environment.
Variant support is live in supported regions now. If your team is already landing JSON to S3 Tables with a schema defined ahead of ingestion, this is the right moment to evaluate whether the Variant type can simplify that pipeline.
