Deprecate column without dropping / virtual migrations

[djeer]

Hi! We faced a problem that we cannot delete a column.

We use sqlc.embed a lot, and it is essentially is a star expansion over a table's columns, which gets transformed to all columns named individually in the query. The problem is, that if we have a column that we never use in our code, the final query still individually references this column. If we do DROP COLUMN, then a production deploy breaks running code because the column is not available and cause an incident.

The only path I see as a workaround is to:

1. Create unstaged migration
2. Run SQLC generate
3. Commit codegen without the migration in PR A
4. Commit migration in PR B
5. Deploy PR A
6. Deploy PR B

But it also contradicts our CI, which checks that codegen matched the code (need to disable CI checks) and there's also a chance other developer can merge something between A and B, so we have to schedule merge moratorium to do that.

Is there a way to deprecate a column that I am missing? We are using Encore for migrations, and it does not allow to add a "virtual" migrations that would be skipped.

[guilhermelinosp]

I don't think this should be solved with a virtual migration. This is fundamentally an expand/contract deployment problem.

sqlc.embed(table) expands the table into its columns, so the generated SQL has a runtime dependency on every embedded column. Dropping one while an older application version is still running is therefore a breaking schema change.

I would use two deployments.

First, stop referencing the column while it still exists:

-- before
SELECT sqlc.embed(users)
FROM users;

-- transition
SELECT id, name, email
FROM users;

Regenerate the Go code and deploy that version everywhere.

At this point:

database: old column still exists
new application: no longer references it
old application: still works

Only after all old application replicas have been replaced should the second migration run:

ALTER TABLE users DROP COLUMN deprecated_column;

This gives you:

1. Remove runtime dependency
2. Deploy application
3. Verify old version is gone
4. Drop database column

sqlc verify is useful here as an additional safety check because it is specifically designed to detect schema changes that break existing queries.

The core issue is that sqlc.embed() has no concept of a "deprecated but don't generate this column" state. If you need zero-downtime schema evolution, explicit projections are safer than embedding an entire table across a destructive migration boundary.

So I would keep CI enabled and change the query first rather than generating code from an uncommitted/virtual schema.