Have read the migration guide, and kind of read this “if possible, and falls back to timestamp" = will work.

The “if possible” part refers to dialect capability.

This config-change, will it work in the long run (incubating)?

We might change the way how this is configured to have a uniform configuration for all non-trivial Java types, but yes, you will always have an option to configure the default. I’d recommend you to change the datatype on the database side though and avoid the configuration, because this will avoid possible confusions about “what time zone is that timestamp in?”.

I can understand the asking for trouble, problem here is our database is already there, and it worked in hibernate 5.x

You’re doing a major version upgrade from Hibernate 5 to 6, so these sorts of behavior changes should be expected. That’s what major versions are for. If Hibernate 6 we were fully backwards compatible, we would have called it Hibernate 5.7.

So what do you suggest we should do in this case, to be future proof?

You can use the config for the meantime until you finish your migration, but long term, I’d suggest you get rid off the columnDefinition in your entity model and change the database type to timestamp with time zone.