[thunderfork]

This seems like the kind of tool you would only use where you have the following needs:

1. Not leaking timestamp data (security/regulations)

2. Having easily time-sortable primary keys (DB performance/etc.)

If you don't have both of these needs, the tool is an unnecessary indirection, as you've identified in (2).

However, where you do have both needs, some indirection is necessary. Whether this is the correct one is a different question.

Similarly, if you _must not_ leak timestamps for some real-world reason, (1) is an intrinsic requirement, consumers be damned.

[the_mitsuhiko]

If you must not leak timestamps then you also cannot really have timestamp ordering internally because you will happen to start leak that out in other ways through collection based endpoints.

[JimDabell]

Not necessarily. For instance, in situations where unprivileged users can only see single items but privileged users can see collections. But yeah, time-ordering leaks information to people who can see the collection.

[inopinatus]

This scheme potentially leaks timestamp, serialisation, and record-correlation data because the specification of UUIDv7 allows for partial timestamps and incrementing counters in the so-called random bits, which are passed through undisturbed.

So it is not generally fit for that purpose either.

[AprilArcus]

Those seem like standard needs for any kind of CRUD app, so I would call this approach pretty useful. Currently I do something similar by keeping a private primary uuidv7 key with a btree index (a sortable index), and a separate public uuidv4 with a hash index (a lookup index), which is a workable but annoying arrangement. This solution achieves the same effect and is simpler.

[nightpool]

Why can't you leak timestamp data? What timestamp data is sensitive to your system?

Also, why use UUIDs in that case?