What Are DDL, DML, DCL and TCL?

They are four buckets that split the SQL grammar by what the statement changes and, crucially, by what the engine does when it fails.

DDL — Data Definition Language. Changes the shape of the database: CREATE, ALTER, DROP, TRUNCATE, CREATE INDEX, CREATE VIEW. It edits the schema, not the rows. This is the category that shows up in a migration file and the one most likely to lock a table.

DML — Data Manipulation Language. Changes the rows: SELECT, INSERT, UPDATE, DELETE, and the MERGE family. It is the bucket your application spends all day inside, and the one covered by transaction semantics.

DCL — Data Control Language. Changes who is allowed to do what: GRANT, REVOKE, CREATE USER, CREATE ROLE. In managed cloud databases this is often replaced by an external identity provider, but the concept stays.

TCL — Transaction Control Language. Controls transaction boundaries: BEGIN/START TRANSACTION, COMMIT, ROLLBACK, SAVEPOINT. It does not change data on its own; it decides whether the DML inside it survives.

The reason interviewers care about the split is operational. DML is usually rollback-able and transaction-safe; DDL in some engines forces an implicit commit and is not. That single fact decides whether a schema migration can be made atomically.

Classify a statement by asking what it changes: the shape of the database, the rows inside it, the permissions around it, or the transaction boundary around it.

-- TCL: opens the transaction that the DML below belongs to
BEGIN;

-- DDL: changes the schema, not the rows
CREATE TABLE audit_log (
  id INTEGER PRIMARY KEY,
  action TEXT NOT NULL,
  logged_at TEXT NOT NULL DEFAULT (datetime('now'))
);

-- DML: changes rows
INSERT INTO audit_log (action) VALUES ('user.signup');
UPDATE audit_log SET action = 'user.registered' WHERE action = 'user.signup';

-- DCL: changes who may do what (privilege syntax is engine-specific)
-- GRANT INSERT ON audit_log TO app_user;

-- TCL: makes the changes durable
COMMIT;

The CREATE TABLE is DDL because it defines a new relation, and it runs before the table holds any rows. The INSERT and UPDATE are DML because both operate on the rows inside an existing relation — the first adds one, the second rewrites one. The GRANT line, commented out because SQLite has no role system, is DCL: it grants a privilege rather than touching schema or data.

The COMMIT is TCL. It is not DML even though it follows DML, because it does not itself insert or update anything — it closes the transaction and makes the preceding changes durable.

Two details an interviewer may probe. First, the DEFAULT (datetime('now')) expression is evaluated per row at insert time, and SQLite allows a parenthesised expression there where MySQL wants a bare function call in some versions. Second, note that CREATE TABLE in SQLite is transactional and rolled back with the rest of the transaction, while the same statement in MySQL performs an implicit commit — so the category alone does not tell you how it behaves on failure.

Because a migration is only safe if it is atomic. Imagine adding a nullable column, then adding an index on it, then backfilling values. If the third step fails, an atomic migration rolls all three steps back and the database is untouched. If the engine auto-commits each DDL statement, the first two steps are already permanent when the third one errors — the schema is half-migrated and the next deploy starts from a state nobody designed.

-- A transactional DDL migration in SQLite and PostgreSQL.
CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  total REAL NOT NULL
);
INSERT INTO orders (total) VALUES (10.0);

BEGIN;

ALTER TABLE orders ADD COLUMN status TEXT DEFAULT 'new';

CREATE INDEX idx_orders_status ON orders (status);

UPDATE orders SET status = 'new' WHERE status IS NULL;

COMMIT;

SELECT id, total, status FROM orders;

Run against SQLite this is one unit of work: if any statement inside fails, ROLLBACK removes the column, the index and the backfill together. MySQL behaves differently — DDL statements there cause an implicit commit, so the ALTER TABLE above is durable the moment it succeeds, no matter what happens later in the script. The standard mitigation on MySQL is to write migrations as carefully ordered, individually idempotent steps, so re-running the script after a failure converges on the desired schema rather than half-applying it.

Two other production hazards ride along. A ALTER TABLE that rewrites the whole table takes an exclusive lock and blocks reads for the duration on older MySQL versions, which is why online DDL tools exist. And a migration that assumes a column does not yet exist will fail on the second attempt unless it checks the current schema first — idempotence is the property that makes retries safe.