I can see the ordering works when @NaturalId is not used but when used it does not work.

The decision to reorder @UniqueConstraint columns seems weird to me, since the annotation already contains an explicit order that I have chosen intentionally. I guess I’ll need to convert all of those to @Index annotations. (Edit: Looks like the reordering of @UniqueConstraint columns was fixed in .)

You can replace the reproducer’s @Table annotation with @Table(indexes = @Index(name = "UK_zipCode_city", unique = true, columnList = "zipCode,city")), which will result in identical behaviour. The table’s uniqueKeys will only contain the unique key UK_ssg5bhovsjy4wr4uyeojlnji7 with the columns ordered alphabetically as city, zipCode. The table’s indexes are empty.

Recently it has been changed to order many things alphabetically. This results in @UniqueConstraint having columns ordered, same as primary key columns. There is a pending PR for changing this behavior for primary key. (please see here). @Index creates a database index, so it should preserve the order of columns you specify. Could you create a reproducer demonstrating order of columns not preserved from @Index please?

Edit: Or is it the same reproducer you attached just switching the @UniqueConstraint for @Index?

Using @UniqueConstraint to specify the column order worked previously. Is there a reason why @Index is preferred?

(In this case @Index with unique = true doesn’t work either. It’s ignored, just like the @UniqueConstraint.)

Hi,

for specifying the column order for the unique constraint you should opt for using @Index with property unique=true