UUIDs support varies wildly between databases; in Hibernate ORM 5, last time I checked, it had serious problems on H2 in particular (and most likely other DBs as well). Sequence support being very slow, on the other hand, is specific to CockroachDB (because it’s distributed). Hence the initial choice.

That being said, UUID would indeed be interesting if it doesn’t require a database roundtrip.

There are some constraints:

• There needs to be at least decent support for all tested databases: H2, Postgresql, Oracle, MariaDB, MySQL, DB2, MS SQL, CockroachDB. Our CI can check that.
• We need to offer a migration strategy from the old schema to the new one (probably SQL scripts, one for each tested database): even though this feature is incubating, I’d rather be nice with people who already started using it. I’d add a dedicated test for that.
• It would be better for UUIDs to be time-based, i.e. at least somewhat ordered according to the time of the event. While not strictly necessary, this will help make sure that no event is left unprocessed for a very long time when there’s a lot of events being produced.
  This means in particular using CustomVersionOneStrategy , at least by default (see https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#identifiers-generators-uuid ). I believe making the strategy configurable would be a good idea, since I’m not sure CustomVersionOneStrategy will always correctly detect the IP address of the application (it may pick 127.0.0.1).
• The implementation of UUID generation needs to really be conflict-free. We expect multiple application instances to generate events, many of them, all the time, and we really don’t want conflicts that would trigger a transaction rollback, especially for DBs other than CockroachDB where such rollbacks are not “business as usual”.
  On that front, time-based UUIDs seem like a good option too, since they rule out conflicts between multiple instances (since they theoretically include a unique identifier for the application instance), as well as within a single application instance (since they include a counter whose value is unique in a given JVM, at least as long as there’s fewer than 65000 events in a single millisecond).

I would gladly accept a pull request that complies with all the constraints above. herzhang do you want to give it a shot?