EasySQL#37 min readJul 11, 2026

DDL vs DML vs DCL vs TCL

practicelearning

Practice modeTest yourself instead of reading straight through

Hook: Interviewers love this question because it quickly shows whether you understand the database as four different jobs: building the structure, changing the data, controlling access, and protecting multi-step work.

Question: What is the difference between DDL, DML, DCL, and TCL in SQL?

Answer: DDL changes the database structure, like creating or altering tables. DML changes the data inside tables, like inserting, updating, or deleting rows. DCL manages permissions, and TCL manages transactions so a set of changes can succeed or fail together.

Interview-Ready Answer: I’d say DDL defines structure, DML works with data, DCL controls permissions, and TCL controls transaction boundaries. For example, CREATE TABLE is DDL, INSERT and UPDATE are DML, GRANT and REVOKE are DCL, and COMMIT and ROLLBACK are TCL. One useful detail is that DDL behavior can vary by database: some systems auto-commit DDL, while others allow it inside a transaction.

Memory map — visual summary of this topic — 🧠 Memory Map

What each category really means

DDL means Data Definition Language. It changes the schema (the blueprint of the database): tables, columns, constraints, indexes, and sometimes views.

DML means Data Manipulation Language. It reads or changes the rows inside those tables.

DCL means Data Control Language. It controls who can do what.

TCL means Transaction Control Language. It controls whether a group of changes becomes permanent or is undone.

How they work under the hood

DDL updates metadata. The database stores table definitions in system catalogs or data dictionary tables. When you run CREATE or ALTER, the engine changes that metadata first, then may also rewrite physical storage if the schema change needs it.
DDL may take a lock. A lock is a short-term block that prevents conflicting work. A table-level schema change can block reads or writes while the engine protects the structure.
DML changes rows. When you run INSERT, UPDATE, or DELETE, the engine writes row changes, updates indexes, and records the work in the transaction log so it can be committed or rolled back.
DCL updates privileges. GRANT and REVOKE change authorization rules, often stored in system tables. The exact syntax can vary by database; for example, some systems also support DENY.
TCL controls the log boundary. BEGIN, COMMIT, ROLLBACK, and SAVEPOINT decide whether changes are final. Until commit, the database can undo uncommitted work using undo or log records.

Fast comparison

Type	Goal	Examples	Typical effect
DDL	Change structure	CREATE, ALTER, DROP	Schema/catalog change
DML	Change data	INSERT, UPDATE, DELETE, SELECT	Row-level change/read
DCL	Change access	GRANT, REVOKE	Permission change
TCL	Control atomicity	COMMIT, ROLLBACK, SAVEPOINT	Finalize or undo work

When and why to use them

DDL during schema design and migrations: adding a column, creating an index, dropping a table.
DML inside application features: checkout, profile updates, search filters, reporting queries.
DCL when setting up users, roles, and least-privilege access.
TCL when several statements must succeed together, like placing an order and reducing inventory in one atomic unit.

Important edge cases

SELECT nuance: Many interviews group SELECT under DML, but some people call read-only queries DQL (Data Query Language). If you mention that distinction, you sound careful and precise.
TRUNCATE ambiguity: It removes rows, but many databases treat it more like DDL because it deallocates storage and may auto-commit.
DDL transaction behavior differs: PostgreSQL can roll back many DDL statements; MySQL often issues an implicit commit for many DDL operations; SQLite supports transactional DDL.
Cost is not equal: A small INSERT is usually cheap; an ALTER TABLE on a huge table can block traffic for seconds or minutes.

Memory note: Think of the database like a building: DDL builds the rooms, DML moves the furniture, DCL decides who gets a key, and TCL decides whether the move is final or gets undone.

Real-world story

In an e-commerce checkout service, the application uses DML to insert an order row and update inventory, and it uses TCL to commit both changes together. The platform team uses DDL during deployments to add columns or indexes, and the security team uses DCL to give the app service account only the permissions it needs.

Here is what goes wrong when someone misunderstands the difference: a developer runs an ALTER TABLE on the live orders table during peak traffic, thinking it is just a harmless change to metadata. In reality, the DDL takes a schema lock, requests pile up, checkout latency jumps, and the logs start showing lock waits or blocked sessions. Users see timeouts at payment step, support gets complaints about stuck carts, and the database team has to cancel the migration and drain traffic.

The lesson is simple: DDL can affect availability even when no rows are being edited, while TCL is what protects multi-step business actions from becoming half-done.

SQL

-- Demonstration of DDL, DML, TCL, and a note about DCL.
-- Run this in a fresh SQL session or scratch database/schema.

DROP TABLE IF EXISTS demo_accounts;

-- DDL: define the table structure.
CREATE TABLE demo_accounts (
    account_id INTEGER PRIMARY KEY,
    owner_name VARCHAR(50) NOT NULL,
    balance DECIMAL(10,2) NOT NULL CHECK (balance >= 0)
);

-- DML: put rows into the table.
INSERT INTO demo_accounts (account_id, owner_name, balance) VALUES
    (1, 'Ava', 100.00),
    (2, 'Noah', 50.00),
    (3, 'Mia', 25.00);

-- TCL: start one atomic unit of work.
BEGIN TRANSACTION;

-- DML inside a transaction: this change is not final until COMMIT.
UPDATE demo_accounts
SET balance = balance - 20.00
WHERE account_id = 1;

-- Edge case / error-handling pattern: save a point so we can partially undo.
SAVEPOINT after_debit;

-- Suppose we realize the credit target is wrong before committing.
-- Roll back only the last step, not the whole transaction.
UPDATE demo_accounts
SET balance = balance + 20.00
WHERE account_id = 2;

ROLLBACK TO SAVEPOINT after_debit;

-- Fix the mistake and apply the correct credit.
UPDATE demo_accounts
SET balance = balance + 20.00
WHERE account_id = 3;

COMMIT;

-- Final state check.
SELECT account_id, owner_name, balance
FROM demo_accounts
ORDER BY account_id;

-- DCL is about permissions. Syntax is database-specific, so keep it as a comment here.
-- Example idea: GRANT SELECT ON demo_accounts TO reporting_user;
-- Example idea: REVOKE INSERT ON demo_accounts FROM reporting_user;

Follow-up & Tricky Questions:

Which SQL statements belong to DDL, DML, DCL, and TCL? A strong answer lists the common ones: DDL = CREATE, ALTER, DROP; DML = INSERT, UPDATE, DELETE, often SELECT; DCL = GRANT, REVOKE; TCL = COMMIT, ROLLBACK, SAVEPOINT.
Is SELECT DML? In many interview settings, yes, because it is part of data manipulation/querying. If you want to be extra precise, say some people separate read-only queries into DQL, but the common grouping still puts SELECT with DML.
What happens if a DDL statement runs inside a transaction? It depends on the database. PostgreSQL often allows transactional DDL, while many MySQL DDL operations cause an implicit commit, so you cannot always roll them back.
What is the difference between COMMIT and ROLLBACK? COMMIT makes the current transaction permanent; ROLLBACK undoes all uncommitted changes since the last commit or savepoint.
Why use SAVEPOINT instead of rolling back everything? It lets you undo only part of a transaction, which is useful when one step fails but earlier safe work should be kept in the same transaction.
When would you use GRANT instead of changing the application code? Use GRANT when the problem is access control, not logic. For example, give a reporting user read-only access without giving it write or drop privileges.
Tricky: Is TRUNCATE DML or DDL? Most candidates say DML because it removes rows, but many databases treat it as DDL because it resets storage more aggressively and may auto-commit.
Tricky: Can a table still exist if a transaction rolls back? Yes, if the table was created by DDL that was already committed or if your database does not roll back that DDL. Behavior depends on the engine, so never assume all schema changes are fully reversible.
Tricky: Does DELETE always erase data immediately? Not necessarily. It marks rows for deletion inside the transaction first; the change becomes permanent only after COMMIT.

Common Mistakes:

Mixing up DML and DDL. Correction: DDL changes structure; DML changes rows.
Forgetting that SELECT is often treated as DML in interviews. Correction: mention the DQL nuance so you sound precise, not confused.
Assuming every database rolls back every DDL statement. Correction: DDL transaction behavior is engine-specific.
Thinking permissions are part of TCL. Correction: permission changes are DCL; transactions are only about making work atomic.

Memory Hook: Blueprint, Brush, Badge, Brake: DDL builds the blueprint, DML moves the brush over the data, DCL shows the badge that grants access, and TCL is the brake pedal that stops or commits the ride.

Cheat Sheet:

DDL = structure: CREATE, ALTER, DROP.
DML = data rows: INSERT, UPDATE, DELETE, often SELECT.
DCL = permissions: GRANT, REVOKE.
TCL = transaction control: COMMIT, ROLLBACK, SAVEPOINT.
DDL can lock objects and may auto-commit in some DBMSs.
TCL is what protects multi-step business actions from partial failure.

Practice Tasks:

Write one example statement for each category from memory.
Create a small table, insert rows, update one row, then rollback a transaction.
Explain why adding an index is not the same as changing a row value.

Back to Questions←→to navigate

Type

Goal

Examples

Typical effect

DDL

Change structure

CREATE, ALTER, DROP

Schema/catalog change

DML

Change data

INSERT, UPDATE, DELETE, SELECT

Row-level change/read

DCL

Change access

GRANT, REVOKE

Permission change

TCL

Control atomicity

COMMIT, ROLLBACK, SAVEPOINT

Finalize or undo work

-- Demonstration of DDL, DML, TCL, and a note about DCL. -- Run this in a fresh SQL session or scratch database/schema. DROP TABLE IF EXISTS demo_accounts; -- DDL: define the table structure. CREATE TABLE demo_accounts ( account_id INTEGER PRIMARY KEY, owner_name VARCHAR(50) NOT NULL, balance DECIMAL(10,2) NOT NULL CHECK (balance >= 0) ); -- DML: put rows into the table. INSERT INTO demo_accounts (account_id, owner_name, balance) VALUES (1, 'Ava', 100.00), (2, 'Noah', 50.00), (3, 'Mia', 25.00); -- TCL: start one atomic unit of work. BEGIN TRANSACTION; -- DML inside a transaction: this change is not final until COMMIT. UPDATE demo_accounts SET balance = balance - 20.00 WHERE account_id = 1; -- Edge case / error-handling pattern: save a point so we can partially undo. SAVEPOINT after_debit; -- Suppose we realize the credit target is wrong before committing. -- Roll back only the last step, not the whole transaction. UPDATE demo_accounts SET balance = balance + 20.00 WHERE account_id = 2; ROLLBACK TO SAVEPOINT after_debit; -- Fix the mistake and apply the correct credit. UPDATE demo_accounts SET balance = balance + 20.00 WHERE account_id = 3; COMMIT; -- Final state check. SELECT account_id, owner_name, balance FROM demo_accounts ORDER BY account_id; -- DCL is about permissions. Syntax is database-specific, so keep it as a comment here. -- Example idea: GRANT SELECT ON demo_accounts TO reporting_user; -- Example idea: REVOKE INSERT ON demo_accounts FROM reporting_user;

Follow-up & Tricky Questions:

Which SQL statements belong to DDL, DML, DCL, and TCL? A strong answer lists the common ones: DDL = CREATE, ALTER, DROP; DML = INSERT, UPDATE, DELETE, often SELECT; DCL = GRANT, REVOKE; TCL = COMMIT, ROLLBACK, SAVEPOINT.
Is SELECT DML? In many interview settings, yes, because it is part of data manipulation/querying. If you want to be extra precise, say some people separate read-only queries into DQL, but the common grouping still puts SELECT with DML.
What happens if a DDL statement runs inside a transaction? It depends on the database. PostgreSQL often allows transactional DDL, while many MySQL DDL operations cause an implicit commit, so you cannot always roll them back.
What is the difference between COMMIT and ROLLBACK? COMMIT makes the current transaction permanent; ROLLBACK undoes all uncommitted changes since the last commit or savepoint.
Why use SAVEPOINT instead of rolling back everything? It lets you undo only part of a transaction, which is useful when one step fails but earlier safe work should be kept in the same transaction.
When would you use GRANT instead of changing the application code? Use GRANT when the problem is access control, not logic. For example, give a reporting user read-only access without giving it write or drop privileges.
Tricky: Is TRUNCATE DML or DDL? Most candidates say DML because it removes rows, but many databases treat it as DDL because it resets storage more aggressively and may auto-commit.
Tricky: Can a table still exist if a transaction rolls back? Yes, if the table was created by DDL that was already committed or if your database does not roll back that DDL. Behavior depends on the engine, so never assume all schema changes are fully reversible.
Tricky: Does DELETE always erase data immediately? Not necessarily. It marks rows for deletion inside the transaction first; the change becomes permanent only after COMMIT.