Deprecating some columns from a Drizzle schema

[tpilewicz]

When deleting a column from a table (to replace it with another column), my process is:

• PR1: introduce a new column that is meant to replace it, fill it with some script.
  • at this point, the code still uses the old column, because the new column is empty until the script is run.
• PR2: the code now uses the new column, which is made not nullable. Deprecate the old column, by deleting it from the schema, so we're sure the code cannot use the old column (you would get type errors).
  • The PR does not generate a migration to actually drop the column, because until the new version of the code is fully deployed, we can't be sure it's absolutely safe to drop it. (the CI first runs the schema migrations, then only deploys the new code gradually)
• PR3: generate the actual migration to drop the old column.

It would be nice if PR2 didn't have to delete the old column from the schema to ensure that the application code doesn't use it anymore. Instead, it could use some kind of setting on the old column, that allows "deprecating" it. It would mean that the column is not visible anymore in the table's typescript type, but drizzle-kit wouldn't generate a migration to drop it. Something like: description: text('description').$deprecated()

The reason I'm suggesting this is that I find it awkward to accept that in some situations, there is a difference between the typescript schema and the DB schema. We try to run some tests as part of our CI to prevent people from merging things when such a discrepancy exists (the test generates a schema migration, and returns a failure if it was able to generate it). Some option to flag the columns where this discrepancy is expected would be useful.

I looked for this in the docs, but maybe I searched a bit too specifically for deletion of columns, and should have been looking for manipulating types in general?

Thanks for reading, and for maintaining a great tool!

[tpilewicz]

Actually the real issue you will encounter if the same PR deletes the column from the Drizzle schema + creates the migration to drop it is not about typings, but about the SQL that Drizzle will generate. Assuming that the schema migration is run first and then only the new code is deployed, between these two events, any select or insert to the table will try to select/insert the dropped column, and will throw a database error.

[pesterhazy]

I'm running into the same issue with dropping columns in a safe way.

When I remove a column from the schema, that will cause a migration to be generated when I run generate. However, that migration is NOT safe to run, because the production system will expect the column to be there, even if not used in the code.

One hack that I've used is to do this in two steps:

• Remove the column from schema.ts. Manually edit the migration file to say "SELECT 42". Deploy this change, wait until all processes have been updated
• Add a custom migration that actually drops the column. Now it's safe to run this

This is harder than it should be and support for this in drizzle would be helpful (even a guide section in the docs on how to safely do migrations would help)

[tpilewicz]

A workaround is to do it in two steps:

• in a PR, make sure that no parts of the code at all write to / read from the deprecated column. This means updating all inserts / updates / selects in the code, and updating all .query.finds as well.
• then you do a second PR dropping the column from schema + generating the drizzle migration.

I still think some option to deprecate a column would be nice, it would achieve the first PR at the schema level, which would be less tedious and give stronger guarantees than "I think we're not using it anymore".

[cooldev227]

What you're describing is a schema/code-generation concern rather than a database-level deprecation.

I checked the current Drizzle documentation and repository discussions. Drizzle currently treats the TypeScript schema as the source of truth for migration generation, so removing a column from the schema naturally causes drizzle-kit to interpret it as a database change.

I also found a GitHub Discussion that is essentially the exact feature request you're describing: “Deprecating some columns from a Drizzle schema.” The proposed workflow is the same three-step process you outlined, and the author specifically suggested something like $deprecated() so the column disappears from TypeScript types without causing Drizzle Kit to generate a DROP COLUMN.