News for hackers. Stuff that matters.

A comment on UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp). Parent comment

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by thunderfork on Wednesday September 17, 2025 @12:04PM (#45277545)
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.

[ Parent | on HN ]
Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by the_mitsuhiko on Wednesday September 17, 2025 @12:52PM (#45278313)
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.
[ Parent | on HN ]
Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by JimDabell on Wednesday September 17, 2025 @01:10PM (#45278557)
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.
[ Parent | on HN ]
Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by AprilArcus on Wednesday September 17, 2025 @01:45PM (#45279008)
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.
[ Parent | on HN ]
Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by nightpool on Wednesday September 17, 2025 @04:28PM (#45280985)
Why can't you leak timestamp data? What timestamp data is sensitive to your system?

Also, why use UUIDs in that case?

[ Parent | on HN ]
Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by inopinatus on Thursday September 18, 2025 @12:21AM (#45285352)
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.

[ Parent | on HN ]