SQL RENAME COLUMN: Preserve Data While Updating Its Name

The practice task

Rename dept to department in a fictional team directory, then read the same stored value using its new name. The example keeps the data change separate from the naming change.

The data below is fictional. Run the example in a new SQLite database. It was checked with SQLite 3.51.0; other databases may use different syntax, functions or type rules.

Complete worked query

Create the small fixture and run the query together. The IDs, boundary values and missing entries make the result small enough to check by hand.

CREATE TABLE team(id INTEGER, dept TEXT);
INSERT INTO team VALUES (1,'Design'),(2,'Support');
ALTER TABLE team RENAME COLUMN dept TO department;

SELECT id, department FROM team ORDER BY id;

Checked result

This is the result of the exact example above. NULL marks a missing database value rather than the text string "NULL".

Read the result

Both department values remain readable after the rename. The query uses department, matching the new schema name. Nothing in this operation maps Design to a different category or rewrites the business meaning of Support.

Application SQL that still refers to dept needs attention. The database may update some internal dependencies according to its own rules, but that does not edit a query string stored in an application repository or an external report.

A clear name can improve comprehension, yet it can still be an incompatible change for a consumer. Review deployment order when the old and new application versions might run at the same time. The toy exercise demonstrates the field rename, not a complete production migration plan.

Mistakes to check

Use these checks when adapting the example to a different dataset.

• Distinguish a schema rename from a value transformation.
• Search external queries and positional data mappings.
• Check the database version and its dependency-update rules.