What Is Data Definition Language (DDL)?

TL;DR

DDL is the subset of SQL used to define, change, or remove the structure of a database: tables, schemas, columns, indexes, constraints. It's a different job from Data Manipulation Language (DML), which handles the data living inside that structure. CREATE, ALTER, and DROP are the three commands that do almost all the work.

What DDL Actually Does

Every table starts as a DDL statement. CREATE TABLE orders (order_id INT, customer_id INT, order_total DECIMAL) is DDL: it builds the container. Once that container exists, DML statements like INSERT, UPDATE, and DELETE fill it and change what's inside. Confuse the two and you'll spend an afternoon trying to INSERT your way into a schema change that was never going to work.

The Core Commands

CREATE builds a new object: a table, a view, an index, a schema. ALTER changes an existing object: add a column, change a data type, add a constraint. DROP removes an object entirely, and unlike DELETE, it takes the structure with it, not just the rows. A handful of other commands round it out, TRUNCATE clears a table's data while keeping its structure, and RENAME does exactly what it says.

DDL vs. DML: Why the Line Matters

DML operations are usually transactional and reversible within a session. DDL operations, in most databases, commit immediately and can't be rolled back the same way. Running an ALTER TABLE on a production table during business hours without understanding that distinction is one of the more common ways a routine schema change turns into an incident.

Where DDL Fits in a Modern Pipeline

Every dbt model that materializes a table is generating DDL behind the scenes. Every schema migration tool, Flyway, Alembic, Liquibase, is essentially a version control system for DDL statements. As pipelines get more automated, the DDL layer is often the part still written by hand, which is exactly where schema drift and silent breaking changes tend to creep in.

How Maia Handles DDL

Every dbt model and every schema migration generates DDL somewhere in the chain, and that's usually the layer still written and reviewed by hand even in otherwise automated pipelines. Maia generates the CREATE and ALTER statements a pipeline needs as part of building it, and when a source schema changes upstream, Maia works out what DDL the warehouse actually needs and applies it under your governance rules, rather than leaving an engineer to write the ALTER TABLE statement manually and hope nothing downstream breaks.