By Azzam Bilal Chamdy 
SEATTLE — In a major expansion of its cloud storage and analytics capabilities, Amazon Web Services (AWS) has announced full support for all data types and advanced features within the Apache Iceberg V3 specification across Amazon S3 Tables.
The announcement, detailed by AWS storage expert Daniel Abib, marks a pivotal shift for data engineering and analytics teams managing petabyte-scale data lakes. By integrating the latest open-source table format standard, AWS aims to eliminate long-standing performance bottlenecks associated with schema evolution, semi-structured JSON parsing, geospatial data encoding, and high-frequency row-level updates.
Available immediately across all AWS regions where S3 Tables operate, the V3 integration comes at no additional software cost, adhering to standard S3 Tables pricing structures. It promises to streamline architectures for enterprises running complex, high-throughput analytical workloads.
Main Facts: What Amazon S3 Tables V3 Support Entails
Apache Iceberg has rapidly established itself as the open-source industry standard for managing large-scale analytical datasets on cloud object storage. It brings relational database-like capabilities—such as ACID transactions, time-travel queries, and schema evolution—directly to open file formats like Apache Parquet stored in Amazon S3.
However, as data lakes have expanded into tens of billions of rows, organizations utilizing the older Iceberg V2 specification frequently encountered operational friction. Compliance requirements to delete specific user records, the ingestion of unstructured or semi-structured event streams, and the need for precision geospatial analytics often demanded expensive workaround pipelines, inflated storage footprints, and increased query latency.
The integration of Apache Iceberg V3 into Amazon S3 Tables directly addresses these pain points by introducing several core architectural enhancements:
- Deletion Vectors: Replacing V2 positional delete files with a streamlined binary format, deletion vectors drastically reduce the overhead and compaction time required when removing or updating records.
- Row Lineage: Automatically assigning unique identifiers (
_row_id) and sequence numbers (_last_updated_sequence_number) to every record, allowing downstream data pipelines to track changes instantaneously without scanning entire tables. - Native Variant Data Type: Enabling the columnar storage and processing of semi-structured data. Rather than parsing raw JSON strings at query time, execution engines can leverage hidden columns and built-in statistics to prune irrelevant files and accelerate queries.
- Extended Data Types: Native support for nanosecond-precision timestamps, unknown data types, geometry, and geography, removing the need to encode these complex formats as generic strings or integers.
- In-Place Upgrades: Allowing data teams to upgrade existing V2 tables to V3 atomically via a simple SQL command (
ALTER TABLE ... SET TBLPROPERTIES ('format-version' = '3')), without requiring manual data rewrites.
Chronology: The Evolution to Iceberg V3 on AWS
The journey toward native Iceberg V3 support on AWS reflects the broader industry migration toward open-table formats and disaggregated storage-compute architectures.
The Rise of Open Table Formats
For years, organizations built data lakes on Amazon S3 using raw file layouts. While cost-effective, these architectures lacked transactional consistency. Apache Iceberg emerged to solve this by introducing a table abstraction layer. AWS steadily expanded its native support for Iceberg, introducing integration across services like Amazon EMR, AWS Glue, and Amazon Redshift.
The Bottlenecks of V2
As data volumes swelled into the petabyte range, V2 limitations became pronounced. For instance, executing a compliance delete of 50,000 user rows from a 2-billion-row table generated thousands of small positional delete files. These fragmented files severely degraded query performance until background compaction processes ran, creating a constant tax on compute resources and storage optimization budgets.
The Introduction of S3 Tables
AWS launched Amazon S3 Tables as a purpose-built storage tier designed specifically to keep Iceberg tables performant and cost-effective as they scale. S3 Tables introduced fully managed capabilities, including automatic compaction, maintenance, replication, and Intelligent-Tiering.
The V3 Integration Milestone
Culminating in the latest announcement, AWS has bridged the gap between its managed storage infrastructure and the advanced capabilities of the Iceberg V3 specification. By supporting deletion vectors, variant types, and row lineage natively within S3 Tables, AWS provides a cohesive environment where storage management and query execution engines operate in lockstep.
Supporting Data: Addressing Real-World Engineering Challenges
To understand the tangible impact of the S3 Tables V3 upgrade, consider the architectural friction points commonly faced by modern data engineering teams, particularly in high-volume sectors like retail analytics, financial services, and digital advertising.
1. Eliminating the Cost of Positional Deletes
In the V2 specification, deleting records required writing positional delete files that pointed to specific file paths and row offsets. When a pipeline processed frequent updates or compliance purges (such as GDPR or CCPA "right to be forgotten" requests), the number of delete files multiplied rapidly. Query engines had to read these files alongside data files, leading to what is known as "read amplification."
Under V3, Amazon S3 Tables utilizes deletion vectors. When a delete operation occurs, a single, compact binary file tracks the modified rows. This architectural change cuts down compaction overhead significantly. S3 Tables’ built-in maintenance cycles automatically clean up these vectors, ensuring queries remain fast without manual intervention.
2. Streamlining Semi-Structured Data with Variant Types
Modern applications generate events with dynamic, highly variable schemas. A retail clickstream table might capture page views with URLs and durations, purchases with item arrays and monetary amounts, and search queries with result counts.
Previously, teams stored these payloads as JSON strings, forcing compute engines to parse strings on the fly during every query—a major CPU and I/O bottleneck.
Iceberg V3 introduces the variant data type, which stores semi-structured data in an optimized columnar format. During ingestion, the engine shreds the variant data into hidden columns and generates granular statistics. When a user runs a query filtering for specific JSON keys, the engine uses these statistics to prune files that do not contain matching data, drastically reducing disk I/O.
3. Powering Incremental Pipelines with Row Lineage
Building efficient Extract, Transform, Load (ETL) pipelines often requires identifying which rows have changed since the last execution. Traditionally, engineers relied on complex watermark columns, full table scans, or expensive joins.
With V3’s row lineage feature, S3 Tables automatically appends _row_id and _last_updated_sequence_number to every record. Downstream jobs can simply query records where the sequence number exceeds a checkpoint value. This enables highly efficient incremental data processing, sparing compute clusters from reading unmodified historical partitions.
Official Responses and Ecosystem Integration
AWS has positioned its S3 Tables V3 support as a cornerstone of its broader analytics ecosystem, emphasizing seamless interoperability across compute engines and data catalogs.
Broad Ecosystem Support
According to AWS engineering leadership, the company offers the most comprehensive native Apache Iceberg support of any major cloud provider. The integration spans every layer of the modern data stack:
- Ingestion and Processing: Teams can write and transform V3 data using Amazon EMR Spark.
- Catalog and Governance: Data governance and schema management are handled via AWS Glue and the Iceberg REST Catalog (IRC) API, ensuring cross-engine compatibility.
- Analytics and BI: Business intelligence analysts and data scientists can query V3 tables directly using Amazon Redshift.
Backward Compatibility and Migration Pathways
Recognizing that migrating large enterprise data lakes to a new standard can introduce operational risk, AWS has engineered V3 support with robust backward compatibility.
- Dual-Version Support: Existing V2 readers can continue to access upgraded tables until engineering teams are fully prepared to adopt V3-specific features.
- Atomic In-Place Upgrades: Upgrading a table requires no data copying or file rewriting; a single SQL statement updates the table properties.
- One-Way Upgrades: AWS notes that because the Apache Iceberg specification does not support downgrading from V3 to V2, teams must verify that all interacting compute engines support the V3 specification prior to executing the upgrade command.
Implications for the Future of Cloud Data Architecture
The introduction of Apache Iceberg V3 support in Amazon S3 Tables signals a broader maturation of the data lakehouse paradigm. As organizations increasingly reject proprietary data silos in favor of open-format architectures built on object storage, the performance gap between traditional enterprise data warehouses and open data lakes continues to narrow.
1. Lower TCO for Large-Scale Data Lakes
By reducing the I/O overhead associated with JSON parsing, eliminating the storage bloat of positional delete files, and minimizing compute cycles spent on full-table scans, S3 Tables V3 helps organizations curb runaway cloud compute bills. Automated maintenance routines further reduce the administrative burden on data engineering teams, allowing personnel to focus on high-value analytics rather than low-level storage tuning.
2. Democratization of Complex Data Types
The native inclusion of variant, geospatial (geometry/geography), and nanosecond timestamp data types lowers the barrier to entry for advanced analytics use cases. Teams no longer need to write custom serialization logic or maintain separate specialized databases to handle location intelligence or high-frequency event streaming; these workloads can now reside natively within the primary analytical data lake.
3. Strengthening Open Standards
As cloud hyperscalers like AWS continue to align their native storage offerings with open-source specifications like Apache Iceberg, vendor lock-in diminishes. Enterprises gain the flexibility to run diverse analytical engines against a unified, governed storage tier without sacrificing performance, security, or reliability.
Getting Started
Data engineering and analytics teams can begin leveraging Apache Iceberg V3 capabilities immediately.
To create a new V3 table or upgrade an existing table bucket, administrators can utilize the Amazon S3 console, interact programmatically via AWS SDKs, or deploy SQL commands through compatible engines like Amazon EMR Spark.
For developers looking to integrate these features into automated workflows, AWS provides extensive documentation through the Amazon S3 Tables User Guide and the Apache Iceberg on AWS Prescriptive Guidance. Furthermore, engineering teams can utilize the AWS MCP Server and associated plugins to query documentation, check regional availability, and troubleshoot deployment parameters using their preferred AI tooling.
Feedback and community discussions regarding the new V3 features can be directed to AWS re:Post or through standard AWS Support channels.
Sagoh 
Siti Muinah 
Reynand Wu 