---
title: "Schema evolution"
description: "Schema evolution is the ability to change a table's structure — adding, removing, renaming, or reordering columns, or widening types — over time without needing to rewrite all existing data or break existing readers."
canonical: "https://motherduck.com/glossary/schema-evolution/"
related:
  - title: "A Duck Walks into a Lake"
    url: "https://motherduck.com/blog/ducklake-motherduck/"
  - title: "Data Transformation | MotherDuck Docs"
    url: "https://motherduck.com/docs/integrations/transformation/"
  - title: "What's New in DuckDB 1.5! | MotherDuck"
    url: "https://motherduck.com/videos/whats-new-duckdb-15/"
---

# Schema evolution

> Schema evolution is the ability to change a table's structure — adding, removing, renaming, or reordering columns, or widening types — over time without needing to rewrite all existing data or break existing readers.

## Overview
Data doesn't stay the same shape forever: new fields get added to source systems, columns get renamed for clarity, and types sometimes need to widen (an integer growing into a bigint, for example). Schema evolution refers to how well a storage system handles these changes gracefully, ideally without a disruptive full rewrite of existing data and without breaking queries or pipelines that expect the old schema.

<glossary-callout guide="duckdb-cheatsheet-full" />

## Schema evolution by format
- **Avro** — designed from the ground up for evolution: a reader can be given both the schema a record was written with and the schema it wants, and Avro resolves compatible differences (like a missing field with a default value) automatically.
- **Parquet** — supports limited schema evolution, mainly by merging compatible schemas across files (for example, a newer file has an extra column that older files lack), but it isn't a first-class feature of the format itself.
- **Iceberg and Delta Lake** — provide full schema evolution as part of the table format: adding, dropping, renaming, and reordering columns are tracked as metadata operations, applied instantly without touching existing data files, because each file's original schema is still recorded and reconciled with the current table schema at read time.

## Why table formats matter here
This is one of the clearest examples of what a table format adds over a bare file format: Parquet alone can hold files with slightly different schemas, but it takes something like Iceberg or Delta Lake to formally track schema versions and evolution history at the table level, and to guarantee old queries keep working against new data.

## Schema evolution in DuckDB
For native DuckDB tables, `ALTER TABLE` supports adding, dropping, and renaming columns directly:

```sql
ALTER TABLE orders ADD COLUMN discount_pct DOUBLE DEFAULT 0.0;
ALTER TABLE orders RENAME COLUMN amount TO order_amount;
```

When reading multiple Parquet files with slightly different columns, DuckDB's `UNION BY NAME` lets you combine them safely by column name rather than position:

```sql
SELECT * FROM read_parquet('data/2025/*.parquet')
UNION BY NAME
SELECT * FROM read_parquet('data/2026/*.parquet');
```