How PostgreSQL and MySQL Handle Column Comments — and Why Developers Skip Them

Both PostgreSQL and MySQL offer native ways to document database columns — COMMENT ON COLUMN and the COMMENT attribute, respectively — but developers rarely use them because adding a comment requires the same migration, review, and deployment process as a structural schema change. PostgreSQL handles this more safely, as its COMMENT ON COLUMN statement only touches the catalog and does not alter table structure. MySQL is more problematic: its column comment is embedded in the column definition, meaning any update via ALTER TABLE can silently drop attributes like DEFAULT values or UNSIGNED constraints if they are not fully restated. This friction means most production databases have thousands of undocumented columns — not from lack of intent, but because the cost of documenting is disproportionately high. One proposed workaround is to store column descriptions in an ERD diagram or data model layer, where changes require no SQL execution against a live database.