[jszymborski]

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.

[hardwaresofton]

You could also "just" have an internal-use only numeric ID, or use a UUIDv7.

[redhale]

TIL about UUIDv7 -- thanks!

[hardwaresofton]

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

[sam_lowry_]

or ULIDs or any other partially sortable ids.

[sebazzz]

ULID are not necessarily sortable, just UUIDs consensed in a shorter string by using more characters than 0-9A-F

[sam_lowry_]

ULID = Unique Lexicographically sortable IDentifier ;-)

[jszymborski]

ULIDs are sorta the opposite of the HMAC method, where you can't query for the nth ID, but you can sort the IDs.