PK isn't the same as public ID, even though you could make them the same. Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.
> Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.
what? that's possible, but it's the worst of both worlds. I've certainly never encountered a system where that's the "normal" practice.
the usual reason people avoid UUIDv4 primary keys is that it causes writes to be distributed across the entire B-tree, whereas sequential (or UUIDv7) concentrates them.
but if you then add a "alternate primary key" you're just re-creating the problem - the B-tree for that unique index will have its writes distributed at random.
> Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.
what? that's possible, but it's the worst of both worlds. I've certainly never encountered a system where that's the "normal" practice.
the usual reason people avoid UUIDv4 primary keys is that it causes writes to be distributed across the entire B-tree, whereas sequential (or UUIDv7) concentrates them.
but if you then add a "alternate primary key" you're just re-creating the problem - the B-tree for that unique index will have its writes distributed at random.
if you need a UUID PK...just use it as the PK.