[staticassertion]

I think ideally your primary key is whatever makes sense for your performance/data model, and then if you want to delegate authority with UUIDs you do that via a separate mapping.

By separating that out you can get a lot:

1. You can extend your delegate system by modifying the delegate table, rather than having to muddy your data model with authority information

2. You can TTL the mappings in the delegate table

3. You can have many mappings to the same data, but each one can have its own restrictions.

It's a bit more complex but you end up with a system that really hones in on the benefit that you're bringing up.

[weird-eye-issue]

That sounds really overkill for simply wanting an identifier that doesn't change, isn't guessable, and doesn't reveal how many rows there are

[staticassertion]

We'll have to agree to disagree. Systems like the ones I described are a hell of a lot easier to build on long term while maintaining those invariants.

[weird-eye-issue]

How is that easier to maintain than literally just having a UUID primary key? I feel like we must be talking about different use cases

[staticassertion]

If your goal is to use the uuid as a delegated capability it's going to be much more complex to use the primary key for your row than to use a separate key.

[weird-eye-issue]

Yeah we are talking about different use cases entirely