Amazon Redshift Adds Apache Iceberg v3 Support with In-Place Deletion Vectors and Row Lineage

AWS has updated Amazon Redshift with native read and write support for Apache Iceberg v3 tables across its Graviton-based provisioned clusters and Redshift Serverless workgroups. The release incorporates three foundational capabilities defined in the Iceberg v3 specification: default column values for backwards-compatible schema evolution, row lineage pseudo-columns for tracking record identity and modification sequence numbers, and deletion vectors that replace Iceberg v2's external positional delete files with compact, compressed bitmaps. For database administrators and platform engineers, high-frequency updates, upserts, and regulatory data purging (such as GDPR or CCPA deletion requests) historically introduced severe performance penalties in Iceberg tables. Under Iceberg v2, each mutation generated separate positional delete files that had to be resolved at read time, necessitating frequent and expensive compaction maintenance. Deletion vectors fundamentally alter this dynamic by storing deletions as inline bitsets, accelerating scan operations on mutated datasets and significantly lowering cluster I/O. Additionally, native row lineage tracking exposes mutation sequence numbers directly through SQL pseudo-columns, streamlining change data capture (CDC) ingestion workflows without requiring custom timestamp columns or auxiliary tracking tables. This enhancement highlights the ongoing evolution of modern cloud databases toward treating open table formats—such as Apache Iceberg, Delta Lake, and Apache Hudi—as primary storage targets rather than second-class external tables. Cloud data warehouses are increasingly shifting their proprietary query engines to operate directly on open lakehouse storage. By adopting Iceberg v3 primitives, Redshift tightens its integration with open data ecosystems while maintaining unified governance via the AWS Glue Data Catalog, allowing shared datasets to be queried interchangeably by Redshift, Apache Spark, and Presto engines without format translation. Practitioners can provision new tables using the v3 format specification (`'format-version' = '3'`) or upgrade existing v2 tables in place using standard `ALTER TABLE` statements. Before migrating existing lakehouse workloads, engineering teams must verify engine compatibility across their broader data platform, as all downstream tools interacting with the storage layer must support the Iceberg v3 specification. Furthermore, current Redshift support is scoped to Graviton-powered instance classes and Redshift Serverless, meaning teams running older hardware generations will need to modernize their cluster instances to take advantage of these capabilities.