gfc64

The point about the storage size of UUID columns is unconvincing. 128 bits vs. 64 bits doesn't matter much when the table has five other columns. A much more salient concern for me is performance. UUIDv4 is widely supported but is completely random, which is not ideal for index performance. UUIDv7[0] is closer to Snowflake[1] and has some temporal locality but is less widely implemented. There's an orthogonal approach which is using bigserial and encrypting the keys: https://github.com/abevoelker/gfc64 But this means 1) you can't rotate the secret and 2) if it's ever leaked everyone can now Fermi-estimate your table sizes. Having separate public and internal IDs seems both tedious and sacrifices performance (if the public-facing ID is a UUIDv4). I think UUIDv7 is the solution that checks the most boxes. [0]: https://uuid7.com/ [1]: https:

I wrote a Ruby gem to address this problem of hiding sequential primary keys that uses a Feistel network to effectively shuffle int64 IDs: https://github.com/abevoelker/gfc64 So instead of /customers/1 /customers/2 You'll get something like /customers/4552956331295818987 /customers/3833777695217202560 Kinda similar idea to this library but you're encoding from an integer to another integer (i.e. it's format-preserving encryption). I like keeping the IDs as integers without having to reach for e.g. UUIDs