DDL vs. DML: What's the Difference (and Why It Matters for Database Change)

Every SQL statement that touches your database falls into one of a few categories, and the two that matter most are DDL and DML. Data Definition Language (DDL) changes the structure of the database. Data Manipulation Language (DML) changes the data inside that structure. The distinction sounds academic until you realize it determines what can be rolled back, who should be allowed to run it, and how much damage a single bad statement can do in production.

This guide covers what DDL and DML are, how their commands differ, and why the difference matters more now than it ever has, especially as AI tools begin generating both.

Critical takeaways:

• DDL defines and modifies database structure: tables, indexes, schemas, views
• DML inserts, updates, deletes, and retrieves the data inside those structures
• In most databases, DDL auto-commits and cannot be rolled back with a simple ROLLBACK
• DML is transactional, but at scale it can be just as destructive as DDL
• Both change types need the same thing: controls that run before deployment, not cleanup after the incident

What Is DDL (Data Definition Language)?

DDL statements define the shape of the database. When you create a table, add a column, build an index, or drop a schema, you are writing DDL. These statements do not touch the rows of data directly. They change the container the data lives in, which is exactly why they carry so much risk. Alter the container and everything inside it, along with every application that depends on it, feels the effect.

CREATE builds a new database object.

CREATE TABLE customers (
  id INT PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  region VARCHAR(50),
  created_at DATE
);

‍

ALTER modifies an existing object.

ALTER TABLE customers
ADD COLUMN account_tier VARCHAR(20);

‍

DROP removes an object entirely, along with all the data in it.

DROP TABLE customers;

‍

TRUNCATE removes every row from a table without logging individual deletions. The structure survives. The data does not.

TRUNCATE TABLE customers;

‍

RENAME changes the name of an existing object, which can silently break every query, view, and application that referenced the old name.

What Is DML (Data Manipulation Language)?

DML statements work with the data itself. They add rows, change values, remove records, and retrieve results. DML is the language of day-to-day application behavior. Every order placed, profile updated, or record archived runs through DML.

The core DML commands:

INSERT adds new rows.

INSERT INTO customers (id, name, region)
VALUES (1042, 'Acme Corp', 'EMEA');

‍

UPDATE modifies existing rows.

UPDATE customers
SET account_tier = 'Enterprise'
WHERE region = 'EMEA';

‍

DELETE removes rows that match a condition.

DELETE FROM customers
WHERE id = 1042;

‍

SELECT retrieves data. Some classifications split SELECT into its own category, Data Query Language (DQL), since it reads without modifying. In practice, most teams group it with DML.

DDL vs. DML: The Key Differences

‍

The Rollback Trap: Why DDL Is the Highest-Risk Change Class

Here is the difference that matters most in production. In most major databases, including MySQL, Oracle, and SQL Server, DDL statements automatically commit the moment they execute. There is no transaction to roll back. Run a DROP TABLE against the wrong environment and the ROLLBACK command will not save you. Your options are restoring from backup or reconstructing the object by hand, and both cost you time you do not have during an incident.

PostgreSQL is the notable exception, supporting transactional DDL. But most enterprises run heterogeneous environments, and a change process built on the assumption that DDL can be undone is a change process that will eventually fail somewhere.

DML behaves differently. Wrap your statements in a transaction, and a mistake can be rolled back before commit. That safety net is real, but it has a hole in it: it only protects you before the commit.

Consider a routine correction to one account:

UPDATE accounts
SET balance = 0
WHERE id = 4021;

‍

One row changes. Now drop the WHERE clause, by accident, in a hurry, or because an AI assistant generated it that way:

UPDATE accounts
SET balance = 0;

‍

Every account in the table is now zero. The statement is valid SQL. It runs cleanly, commits, and reports success. The database has nothing to catch, because nothing is wrong with the syntax. It is a data corruption event that executed exactly as written. DELETE is worse: the same slip removes every row instead of resetting it. This is exactly the failure a policy check is built to stop before it runs.

This is why the DDL vs. DML distinction should shape your change process, not just your vocabulary:

• DDL demands prevention, not recovery. Because you often cannot undo it, the only reliable control is catching a bad statement before it runs. That means review, automated policy enforcement, and rollback scripts written and tested in advance.
• DML demands scoping discipline. The damage almost always comes from scope, not syntax: a DELETE or UPDATE missing its WHERE clause, or a backfill pointed at the wrong environment.
• Both demand an audit trail. When something breaks, the first three questions are always the same: what changed, who changed it, and when. If your DDL and DML changes flow through different processes with different levels of tracking, at least one of those questions will go unanswered.

The pattern underneath all three is the same shift every serious team eventually makes: from coordinating change through reviews, tickets, and tribal knowledge, to enforcing it through controls that run automatically before anything reaches production.

Where the Distinction Breaks Down in Practice

The tidy textbook split between "structure" and "data" gets messier in real delivery pipelines, and the messy parts are where risk concentrates.

TRUNCATE is the classic example. It behaves like a data operation, removing every row, but it is classified as DDL in most systems. It auto-commits, it skips row-level logging, and in many databases it cannot be rolled back. A developer who reaches for TRUNCATE thinking it is a faster DELETE has just removed their own safety net without knowing it.

Database migrations are another. A single migration often mixes DDL and DML: add a column, backfill it with values, add a constraint. If the backfill fails halfway through on a database that auto-committed the schema change, you are left in a state that neither the old code nor the new code expects. Migrations that mix change types need to be planned, sequenced, and tested as a unit, with a recovery path defined for every step.

This gap shows up across the modern data stack too, where transformation tools like DBT shape data but were never built to govern the DDL and DML around them.

And then there is the question of who is writing these statements in the first place.

AI Is Now Writing Your DDL and DML

According to the 2026 State of Database Change Governance Report, 96.5% of organizations allow AI to interact with production databases. Developers are using AI assistants to generate schema changes, and AI agents are increasingly executing data operations directly.

AI produces syntactically valid SQL. What it does not understand is your organization: which schemas are frozen, which naming conventions are mandatory, which tables sit inside compliance scope, which column has a downstream dependency that will break a data pipeline three teams away. A generated ALTER TABLE can pass every syntax check and still violate change controls your auditors will ask about. A generated DELETE can be perfectly formed and scoped to the wrong condition.

The volume of AI-generated changes is rising faster than manual review can keep pace with. That makes the DDL vs. DML distinction operational again: the highest-risk statements, destructive DDL and unscoped DML, need automated enforcement that evaluates every change against your standards before it touches any environment, regardless of whether a human or an agent wrote it.

Governing DDL and DML with Liquibase Secure

Liquibase Secure exists to do one thing well: make sure every database change, structural or data-level, human-written or AI-generated, passes through the same governed path before it reaches production. Safe, repeatable, and provable, by default. It does not design your schema or write your business logic for you. What it governs is how change gets reviewed, enforced, and recorded on the way out the door.

That is what database change governance means in practice. Liquibase Secure applies it across both change types:

• Policy checks evaluate every changeset before deployment. Block destructive DDL like DROP COLUMN outside approved windows, require rollback scripts for schema changes, flag DML that lacks a WHERE clause, and enforce naming conventions automatically instead of in review comments.
• Version-controlled changelogs put DDL and DML changes in the same tracked, ordered, repeatable format, so a migration that mixes both executes as a governed unit rather than a loose script.
• Drift detection catches structural changes that bypassed the pipeline entirely, closing the gap between the schema you approved and the schema actually running in production.
• Targeted rollback reverses a specific problem change without restoring the whole database, which matters most for exactly the changes that databases will not undo on their own.
• Audit-ready evidence records who changed what, when, and where, across both DDL and DML, in a format your compliance team can hand directly to auditors.

This works across 65+ database platforms, which matters because the auto-commit behavior, rollback semantics, and TRUNCATE quirks described above vary by database. A governance layer has to absorb those differences so your teams do not have to memorize them.

FAQ

What is the difference between DDL and DML?

DDL (Data Definition Language) defines and modifies database structure using commands like CREATE, ALTER, and DROP. DML (Data Manipulation Language) works with the data inside that structure using commands like SELECT, INSERT, UPDATE, and DELETE.

Can DDL statements be rolled back?

In most databases, no. DDL auto-commits immediately in MySQL, Oracle, and SQL Server, so ROLLBACK has no effect. PostgreSQL supports transactional DDL and is the main exception. This is why destructive DDL should be blocked or reviewed before execution rather than fixed after.

Is TRUNCATE a DDL or DML command?

TRUNCATE is classified as DDL even though it removes data. Unlike DELETE, it auto-commits in most databases, skips row-level logging, and typically cannot be rolled back.

Is SELECT a DDL or DML command?

SELECT is traditionally grouped with DML. Some classifications place it in a separate category, DQL (Data Query Language), because it reads data without modifying anything.

Why does the DDL vs. DML distinction matter for database change management?

Because the two change types fail differently. DDL failures are often irreversible and require prevention through policy enforcement and pre-written rollback scripts. DML failures are usually scoping errors that commit successfully. A governed change process applies appropriate controls to both before changes reach production.