Amazon S3 Tables now support all Apache Iceberg V3 data types

If you’ve been working with Apache Iceberg on AWS, you’ve probably noticed that data type support felt a bit inconsistent. That’s changing. Amazon S3 Tables—AWS’s managed implementation of Iceberg—now supports the complete set of data types defined in the Apache Iceberg V3 specification. This includes nested complex types like structs, lists, and maps, plus new capabilities like column default values, deletion vectors, and row lineage tracking. For teams building data lakes on S3, this is a meaningful step toward better schema flexibility and data management without the operational overhead.

Let’s talk technically about what’s actually improved. Under the hood, Iceberg V3 extends type support beyond the basics (integers, strings, dates) to handle richer data structures that you’d normally expect from databases. When you define a column with a default value—say, a timestamp that defaults to the current time—that constraint is now stored and enforced at the table metadata level, not just in your application logic. Deletion vectors are equally important: instead of rewriting entire data files to remove a few rows, Iceberg can now mark specific row positions as deleted without touching the underlying Parquet or ORC files. Row lineage tracking adds another layer by recording which source records contributed to which output rows, invaluable for audit trails and debugging data pipelines. These features work across compatible compute engines (Spark, Trino, Athena, and others) because they’re part of the open spec, not proprietary extensions.

Why does this matter for your actual work? Consider a typical scenario: you’re ingesting customer transaction data into S3, and you need to handle late-arriving updates or corrections. Previously, managing deletions or upserts required custom logic and potentially expensive full table rewrites. With deletion vectors, you can mark problematic rows as deleted and only compact affected partitions on your schedule. For analytics teams building dimensional tables, column defaults simplify ETL—you don’t need to backfill a “last_updated” column in every pipeline job; the table handles it. And if compliance requires you to trace how a data quality incident propagated through your warehouse, row lineage gives you that provenance without maintaining separate metadata systems.

Migration is straightforward but worth planning. You can upgrade existing V2 tables to V3, or create new tables with V3 from the start. AWS has included built-in compaction and maintenance operations, meaning you’re not juggling separate tools to manage file fragmentation or optimize performance. If you’re already using S3 Tables with Athena or partnered analytics tools, the upgrade can often happen transparently. The practical takeaway: if your data lakehouse workloads involve complex schemas, frequent updates, or strict compliance requirements, updating to V3 removes friction and unlocks features that previously required workarounds.