> Experts recommend using UUIDv7 only for internal keys and exposing a separate, truly random UUIDv4 as an external identifier.

So then what's the point? How I always did things in the past was use an auto increment big int as the internal primary key, and then use a separate random UUID for the external facing key. I think this recommendation from "experts" is pretty dumb because you get very little benefit using UUIDV7 (beyond some portability improvements) if you're still using a separate internal key.

While I wouldn't use UUIDV7 as a secure token like I would UUIDV4, I don't see anything wrong with using UUIDV7 as externally exposed object keys - you're still going to need permissions checks anyway.

▲

morshu9001 a day ago | parent | next [-]

I asked a similar question, and yeah it seems like this is entirely for distributed systems, even then only some of them. Your basic single DB Postgres should just have a serial PK.

▲

crazygringo a day ago | parent | prev [-]

For distributed databases where you can't use autoincrement.

Or where, for some reason, the ID needs to be created before being inserted into the database. Like you're inserting into multiple services at once.

▲

sgarland a day ago | parent [-]

Many distributed databases have mechanisms to use an auto-increment, actually - often, generating large chunks at a time to hand out.

▲

grapesodaaaaa 17 hours ago | parent [-]

Our “distributed database” at a fortune 90 company spans at least 10 different database products.

UUIDv4 lets us sidestep this.

Is it bad design? Probably. Is it going to happen at huge companies? Yes.

	▲	sgarland 11 hours ago \| parent [-]
		You’re not wrong, of course. It’s a natural consequence of the eschewing of DBAs, and the increasingly powerful compute available - even if someone did notice that the slowdown was due to the PK choice, they can often “fix” that by paying more money.