Consider Check Constraints defined on columns

[CaselIT]

Discussed in #1841

^{Originally posted by ziima August 5, 2026}
With alembic 1.19.0 I discovered a number of remove_constraint operations detected in alembic check output. I looked around a bit and I discovered all are caused by the CheckConstraints defined as part of a column.

E.g. having model as

class Message(BaseModel):
    recipient: Mapped[str] = mapped_column("recipient", CheckConstraint("column_one IS NULL or column_other IS NULL", name="recipient"))

alembic check generates

('remove_constraint', CheckConstraint(<sqlalchemy.sql.elements.TextClause object at 0x7f7874eeee50>, name='message', table=Table('message', MetaData(), Column('x', Integer(), table=<message>), schema=None)))

The part Column('x', Integer() is a literal output, despite all my constraints are TEXT or UUID fields and none of the field is named x.

alembic check works fine, if I move the CheckConstraint to __table_args__ with no other changes.

Do I define the CheckConstraint incorrectly and am I required to define them only at __table_args__ or is that a bug in autogeneration?

[CaselIT]

@zzzeek I propose the following:

• for 2.0/2.1 we handle this in alembic side
• in 2.2+ we change sqlalchemy to register the check constraints on the columns also in the table, since the other constructs do register How to define CheckConstraint properly for autogenerate? #1841 (reply in thread)

(assuming no dragon comes out of hiding if we try to do this change in 2.1)

[sqla-tester]

Federico Caselli has proposed a fix for this issue in the main branch:

Fix autogenerate check constraint https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/6871