Comment by jszymborski
6 days ago
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
With HMAC, you can still ask for some sequential IDs
SipHash128(0, KEY) = k_0
SipHash128(1, KEY) = k_1
You get the same number of bits as a UUID.
You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.
You could also "just" have an internal-use only numeric ID, or use a UUIDv7.
TIL about UUIDv7 -- thanks!
No worries! It's just now finally starting to get everywhere -- Postgres is going to get it in 18 by the looks of things :)
https://www.postgresql.org/docs/18/functions-uuid.html
or ULIDs or any other partially sortable ids.
ULID are not necessarily sortable, just UUIDs consensed in a shorter string by using more characters than 0-9A-F
1 reply →
ULIDs are sorta the opposite of the HMAC method, where you can't query for the nth ID, but you can sort the IDs.