Community guidelines
Be specific and constructive. No vendor spam — promoting your own product belongs in a listing. Anyone can read; posting needs a free account.
we use UUIDv4 for public IDs and bigint internally. UUIDv7 gives us time ordered values, so some developers want to use it as the only primary key on new services. Has anyone seen issues with index locality, privacy or library support?
Index locality is much better than random v4. The main cost is still width. Every foreign key and secondary index carries the larger value. For high volume tables, bigint can still be noticeably smaller.
remember that v7 exposes approximate creation time. That may be fine, but don't assume the ID is completely opaque. Also check monotonic behavior when many IDs are generated in the same millisecond and when clocks move
we already expose created_at in the API, so time leakage isn't a concern. The storage cost might be. Would you still keep a separate public UUID?
For a small service I'd probably use v7 everywhere and enjoy the simpler model. For a giant fact table, I'd measure. There is no universal default. The important change is that you no longer have to accept random insert behavior just to generate IDs outside the database.