One of the main points of using a UUID as a record identifier was to make it so people couldn't guess adjacent records by incrementing or decrementing the ID. If you add sequential ordering, won't that defeat the purpose?

Seems like it would be wise to add caveats around using this form in external facing applications or APIs.

▲

wongarsu 11 hours ago | parent | next [-]

UUIDv7 has a 48 bit timestamp, 12 bits that either provide sub-millisecond precision or are random (in pg they provide precision) and another 62 bits that are chosen at random.

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

	▲	Hizonner 10 hours ago \| parent [-]
		... and the next person working on the system thinks "well, this thing is unpredictable, so it's OK if I leak an unsalted hash of it". If they think at all, which is far from certain. Why does everybody want to find excuses to leave footguns around?

▲

bearjaws 11 hours ago | parent | prev | next [-]

There's still 62 bits of random data, even if you know the EXACT milisecond the row was created (you likely won't), you still need to do 1 billion guesses per second for 73 years.

Ideally you have some sort of rate limit on your APIs...

▲

Demiurge 11 hours ago | parent | prev [-]

The next ID can't be found just by adding 1, can it? How would you guess the next value?