Introduction

Updating multiple columns in one UPDATE statement is standard SQL and usually the right way to make related changes to the same row set. It is clearer, more atomic, and often more efficient than issuing several separate updates for the same records.

Basic Syntax

The core pattern is:

1UPDATE employees
2SET
3    salary = 95000,
4    title = 'Senior Engineer',
5    updated_at = CURRENT_TIMESTAMP
6WHERE employee_id = 42;

Everything after SET is a comma-separated list of column assignments. All assignments happen as part of one statement.

Why One Update Is Better Than Several

If you split related changes across multiple statements, you create extra work and more opportunity for inconsistency.

Bad pattern:

UPDATE employees SET salary = 95000 WHERE employee_id = 42;
UPDATE employees SET title = 'Senior Engineer' WHERE employee_id = 42;
UPDATE employees SET updated_at = CURRENT_TIMESTAMP WHERE employee_id = 42;

Better pattern:

1UPDATE employees
2SET
3    salary = 95000,
4    title = 'Senior Engineer',
5    updated_at = CURRENT_TIMESTAMP
6WHERE employee_id = 42;

The single statement is easier to review and keeps the row transition together.

Use Expressions in the Same Statement

You are not limited to fixed literal values. Each column can be updated with an expression.

1UPDATE inventory
2SET
3    quantity = quantity - 5,
4    last_sold_at = CURRENT_TIMESTAMP,
5    status = CASE
6        WHEN quantity - 5 <= 0 THEN 'out_of_stock'
7        ELSE 'in_stock'
8    END
9WHERE sku = 'A100';

This is a strong pattern because business logic stays consistent within one row update.

Update Multiple Columns from Another Table

Many SQL engines also let you update columns from a joined source. Syntax varies by database, but the idea is common.

PostgreSQL example:

1UPDATE orders o
2SET
3    customer_name = c.name,
4    customer_tier = c.tier
5FROM customers c
6WHERE o.customer_id = c.customer_id
7  AND o.customer_id = 1001;

This is useful for backfills, denormalized summary tables, and repair scripts.

Conditional Multi-Column Updates

You can vary each assignment with CASE so one statement handles several scenarios cleanly.

1UPDATE accounts
2SET
3    status = CASE
4        WHEN failed_logins >= 5 THEN 'locked'
5        ELSE status
6    END,
7    lock_reason = CASE
8        WHEN failed_logins >= 5 THEN 'too_many_failures'
9        ELSE lock_reason
10    END
11WHERE account_id = 77;

This avoids writing one update for status and another update for reason.

Transaction Safety

A single UPDATE statement is usually atomic by itself, but you still need transaction awareness when it is part of a larger workflow.

1BEGIN;
2
3UPDATE accounts
4SET
5    balance = balance - 100,
6    updated_at = CURRENT_TIMESTAMP
7WHERE account_id = 10;
8
9UPDATE accounts
10SET
11    balance = balance + 100,
12    updated_at = CURRENT_TIMESTAMP
13WHERE account_id = 11;
14
15COMMIT;

The point is not that multiple columns require a transaction. The point is that related multi-row operations usually do.

Performance Notes

One multi-column update is usually better than several separate updates on the same rows because:

• fewer round trips
• less repeated locking work
• one clearer execution plan
• one logical change instead of several partial changes

That does not mean every large update is cheap. A wide update against millions of rows can still be expensive, especially if many indexes must be maintained.

Common Pitfalls

The biggest mistake is forgetting the WHERE clause. A multi-column update without a filter can change every row in the table.

Another issue is assuming assignment order matters. In many databases, expressions are evaluated based on the original row values rather than sequentially like imperative code. Check your database rules before relying on one assignment to feed another.

A third problem is spreading related column updates across multiple statements for no reason. That makes auditing and rollback harder.

Summary

• Use one UPDATE statement with a comma-separated SET list to change multiple columns.
• A single statement is usually clearer and more atomic than several smaller updates.
• You can use expressions, CASE, and joined data sources in the same update.
• Be careful with WHERE, especially in production data fixes.
• Treat large or multi-row workflows as transaction design problems, not just syntax problems.