Agree with Caleb, It should not be driver specific but there should be some way to customize it. Checking manually or automatically based on driver attached looks like the solution.
I have posted the same kind of problem here:

It seems related to my problem as well.

In a modelling sense, its a classic many-to-many concern. The issue is that both ends are non-discrete.

On the Dialect side, there can be custom Dialects so a Type saying what Dialects it works for will necessarily miss any custom Dialects. E.g., say that someone writes a custom Dialect for the pgsql-ng JDBC driver. It is impossible for the Hibernate PostgresUUIDType to be able to report that in your suggested Type#getDialectForContribution.

And the same thing on the other side. There can be custom Types. A Dialect reporting its special Types will miss these custom Types in the same way described above.

In fact, the more I think about this TypeContributor is the solution to your request. And unless I hear a compelling argument otherwise, I will close this issue as such.

why does it cause the problems you're referring to if it's a "Type" that works via TypeContributor, but doesn't require users to write their own "TypeContributor" class but rather picks those up via scanning? I would think there wouldn't be any problem if the type itself knew the dialect it's for... or maybe a list of dialects it works for... perhaps I'm missing something. I'm not that passionate on having the types be able to provide it though, I'm just concerned when I see something that is going to turn into

I disagree that Type should be the "driver". It's just as limiting as the inverse case I discussed above where Dialect drives it.