We have applications where we control the creation of the primary key, and where the primary key will be exposed to end users, such as when using a typical web app framework built with Rails, Phoenix, Loco, Laravel, etc. For these applications, UUIDv7 time is too problematic for security, so we prefer binary-stored UUIDv4 even though it's less efficient.
We also have applications where we control the creation of the primary key, and where we can ensure the primary key is never shown to users. For these applications, UUIDv7 is slower at inserts and joins, so we prefer BIGSERIAL for primary key, and binary-stored UUIDv4 for showing to users such as in URLs.
(And why the heck are different types or variants of UUIDs called "versions"?)
it does make sense and it's what you should do instead of using a UUID as PK for this purpose.
You've embrittled your system.
And I say this as someone who recently has to convert some tables from auto increment IDs to uuid. In that instance, they were sharded tables that were relying on the IDs to be globally unique, and made heavy use of the IDs to scan records in time order. So uuids solved both those problems.
An interesting compromise is transforming the UUIDv7 to a UUIDv4 at the API boundary, like e.g. UUIDv47 [1]. On the other hand if you are doing that you can also go with u64 primary keys and transform those
It took me under 15 seconds to come up with that.
Privacy wise,
- Knowing sequential IDs leaks the rate of creation and amount of said entity which can translate in number of customers or rate of sales.
- Knowing timed IDs leaks activity patterns. This gets worse as you cross reference data.
- Random IDs reveal nothing.
---
Security wise,
- Sequential IDs can be guessed.
Performance wise,
- Sequential IDs may result in self-inflicted hotspots.
- Spanner doesn't like writing rows first keyed with timestamps, https://cloud.google.com/spanner/docs/schema-design#primary-key-prevent-hotspots.
It would have to leak sensitive information to be "subtracting security", which implies you're relying on timestamp secrecy to ensure your security. This would be one of the "other problems" the gp mentioned.
If users/products are onboarded in bulk/during B2B account signup, then, leaking the creation times of each of them with any search that returns their UUIDs, becomes metadata that can be used to correlate users with each other, if imperfectly.
Often, the benefits of a UUID with natural ordering outweigh this. But it's something to weigh before deciding to switch to UUIDv7.
Seems like it would be wise to add caveats around using this form in external facing applications or APIs.
Ideally you have some sort of rate limit on your APIs...
The A UUIDv7 leaks to the outside when it was created, but guessing the next timestamp value is still completely unfeasible. 62 bits is plenty of security if each attempt requires an API request
Recursing•2h ago