3 ms·

I think there's a better "You Don't Need UUID", which is that you probably aren't going to generate so many integers per second that you need to do so in a way

I think there's a better "You Don't Need UUID", which is that you probably aren't going to generate so many integers per second that you need to do so in a way that's perfectly collision free. For example, you can update a postgres integer 1000s of times per second, sequentially, and 100s of 1000s of times per second if you allow for gaps/ unordered sequencing. The reason to choose a UUID is because it doesn't require a db. Totally fair. But you probably already have a db lying around if you're generating UUIDs to begin with? Or because you need an unguessable token, which a UUID is great for. But if you have a postgres db around somewhere consider just having a counters table and using that. It'll be fast enough for almost anyone, it'll return smaller tokens, and it'll return tokens that are sequentially allocated (in range. These are nice properties to have!

SoftTalker 3y ago
Database "sequence" types that are used to create integer IDs often no not make any guarantees about being gap-free. This can be a problem for people who don't realize this, and use them for something that is legally required to be gap-free, such as invoice numbers in some jurisdictions. Unguessability is a nice layer to have in your security strategy, especially if you're passing IDs to and from a web page, but if that's all you rely on you're not doing enough.
- insanitybit 3y ago
  > Database "sequence" types that are used to create integer IDs often no not make any guarantees about being gap-free. Yep, the docs from Postgres are very clear that `serial` has gaps. But you can also just create a counter table and manually manage the sequence if you have strict serial requirements. Of course, if you have serial requirements a UUID would already not be viable.