You’ve maybe not had a use case for sortable uuids, so I can provide one:
Columnar databases like Clickhouse don’t have the kind of indices that you’d be used to if you only used OLTP databases like eg Postgres. Instead, you essentially get one index per table, which is the order that things are laid out on disk*
The problem is that you might want 2 access patterns, one for aggregating data within a time range, and another for looking up / joining data by its ID. So which do you use as the index? Timestamp or ID? If the ID is a uuidv4 and you index by ID, your time range queries need to scan the entire table, and vice versa.
If the ID is time-sortable (eg uuidv7), this stops being a problem, and you don’t need some kind of workaround*
* it’s a little more complicated than this but that not in a way that affects the example
* eg a projection of your data with a different index
Columnar databases like Clickhouse don’t have the kind of indices that you’d be used to if you only used OLTP databases like eg Postgres. Instead, you essentially get one index per table, which is the order that things are laid out on disk*
The problem is that you might want 2 access patterns, one for aggregating data within a time range, and another for looking up / joining data by its ID. So which do you use as the index? Timestamp or ID? If the ID is a uuidv4 and you index by ID, your time range queries need to scan the entire table, and vice versa. If the ID is time-sortable (eg uuidv7), this stops being a problem, and you don’t need some kind of workaround*
* it’s a little more complicated than this but that not in a way that affects the example
* eg a projection of your data with a different index