A column that is nullable but never null might indicate that it should be non-nullable but does not necessarily imply so. Say you have an optional comment field, it might just happen by accident that a comment was recorded for each row, but that of course becomes increasingly unlikely with each additional row in the table. There is probably no harm in checking your database for such columns, especially in tables with many rows, but in the end it is up to the semantics of the data model whether a column should be nullable or not. The absence of NULLs is an indicator but not a determiner.

there is also other scenario, field might obviously looks like it should have value, and in check it might event always have it, but it might be "lazy" value.

eg. you might have some bug CSV uploaded and your have number of rows in it, your app could insert record without this number and async process would fill that later.

there might be even some corner case where null value is possible

I believe solution here isn't to check what fields do not use null, but to improve process of creating such migration. either you should create second ticket for next release to update db or commit new migration to some kind of next branch.

> There is probably no harm in checking your database for such columns

The harm is the same as any other unreliable linter rule.

Each one such rule is almost harmless. And on most places that use that kind of rule, they are extremely harmful.