4 ms·

I wouldn't use ULIDs on a new project. The spec doesn't seem like it has much stewardship, the last commit was in 2019 with a bunch of open PRs and issues: htt

I wouldn't use ULIDs on a new project. The spec doesn't seem like it has much stewardship, the last commit was in 2019 with a bunch of open PRs and issues: https://github.com/ulid/spec/issues https://github.com/ulid/spec/issues I went through this exploration a while back for a new project and decided on uuidv7s, which are binary compatible with ULIDs but will likely find more support as they get added to the original UUID RFC. Either UUIDv7 or XIDs seem like better choices than ULIDs for new projects. * Supabase on different primary key considerations: https://supabase.com/blog/choosing-a-postgres-primary-key https://supabase.com/blog/choosing-a-postgres-primary-key * Postgres extension for generating various kinds of IDs: https://github.com/VADOSWARE/pg_idkit https://github.com/VADOSWARE/pg_idkit

sedatk 4y ago
UUIDv7 (and v6, v8 for that matter) hasn't been approved by IETF yet though, has it?
- dwaite 4y ago
  Actively being worked on - https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/ https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122b...
codetrotter 4y ago
> the last commit was in 2019 with a bunch of open PRs and issues I don’t see much of a problem with that. It’s a spec, and is probably considered complete by its authors. The issues and PRs are mostly people wanting to add links to more implementations of the spec to the README. That’s understandable but also not really necessary.
- dwaite 4y ago
  Per the original comment, that doesn't really show stewardship though. If you do not believe a PR or issue to be valid, you close it. If you are literally not willing to accept any PRs or issues, turn the feature off.
  - layer8 4y ago
    What does it matter, assuming the specification is clear and unambiguous?
    - dwaite 4y ago
      if it was clear, unambiguous, and had proper stewardship, there wouldn't be open issues and PRs.
  - codetrotter 4y ago
    I’m not sure if it’s even possible to turn off PR for a repo on GitHub. One of the replies at https://stackoverflow.com/questions/27957454/how-to-disable-pull-requests-in-github https://stackoverflow.com/questions/27957454/how-to-disable-... seems to indicate that it is now possible since quite recently, but the linked post does not seem directly about disabling PRs. Either way, we don’t know if they really don’t want any issues or PRs opened at all just because they have some old issues and PRs still open.
RobertRoberts 4y ago
Why does the spec need updating? As far as I can tell it's finished. Maybe your concern is a little irrational? (fyi, I am very happy user of ULID for years, I don't need libraries to be updated to keep using it) I am wanting UUIDv7 but I can use ULID right now.
- sedatk 4y ago
  I'm not sure about parent's problem, but ULID spec has problems like "monotonic ID" which is just a counter, entirely breaking the universal thing.
  - RobertRoberts 4y ago
    From my experience this is only triggered when generating something like a thousand IDs a second (or more?), something I never run into in the systems I work on. Since _every_ system has a down side or limitation, I am perfectly happy with ULID's flaws. Why should there be disdain or dismissal of a system that solves many people's problems?
tomasreimers 4y ago
Finally! I have a question I've been dying to ask for some time. Most of the time, when I hear people talking about UUIDs being better than big ints, it comes down to big ints leaking data (how many users / posts / comments your site has) and letting an attacker fetch sequential entries (user id 4 works, now try 5). This is even the reasoning in the supabase article. While ULIDs don't reveal the next entry, they do leak data (either creation date or number of entries, as all ULIDs are either prefixed with physical time or logical time). Why don't we just encrypt / decrypt IDs when going over the wire (most API frameworks even have native methods to transform different types of data)? It suffers from neither issue above, is natively supported by API frameworks, and any time used on compute will be dwarfed by network latency. Is this already a pattern and I just don't know about it? EDIT: ahh, below they list one advantage of UUIDs / ULIDs which is you can generate client side. That is reasonable.
andy_ppp 4y ago
Great username, however ULIDs look good and I’d consider using them simply because they solve the problems UUID v7 attempts to solve while being considerably better in some regards and slightly worse in others. I think for my next project I’ll try them instead of UUIDv4. In the end support for something this simple and complete isn’t something I’d have big concerns about.
mirzap 4y ago
Thank you for posting pg_idkit. For months I was searching something like it. Supabase doing great things as well. They have couple others great PG extensions.

sedatk 4y ago

UUIDv7 (and v6, v8 for that matter) hasn't been approved by IETF yet though, has it?

dwaite 4y ago
Actively being worked on - https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/ https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122b...

codetrotter 4y ago

> the last commit was in 2019 with a bunch of open PRs and issues I don’t see much of a problem with that. It’s a spec, and is probably considered complete by its authors. The issues and PRs are mostly people wanting to add links to more implementations of the spec to the README. That’s understandable but also not really necessary.

dwaite 4y ago
Per the original comment, that doesn't really show stewardship though. If you do not believe a PR or issue to be valid, you close it. If you are literally not willing to accept any PRs or issues, turn the feature off.
- layer8 4y ago
  What does it matter, assuming the specification is clear and unambiguous?
  - dwaite 4y ago
    if it was clear, unambiguous, and had proper stewardship, there wouldn't be open issues and PRs.
- codetrotter 4y ago
  I’m not sure if it’s even possible to turn off PR for a repo on GitHub. One of the replies at https://stackoverflow.com/questions/27957454/how-to-disable-pull-requests-in-github https://stackoverflow.com/questions/27957454/how-to-disable-... seems to indicate that it is now possible since quite recently, but the linked post does not seem directly about disabling PRs. Either way, we don’t know if they really don’t want any issues or PRs opened at all just because they have some old issues and PRs still open.

RobertRoberts 4y ago

Why does the spec need updating? As far as I can tell it's finished. Maybe your concern is a little irrational? (fyi, I am very happy user of ULID for years, I don't need libraries to be updated to keep using it) I am wanting UUIDv7 but I can use ULID right now.

sedatk 4y ago
I'm not sure about parent's problem, but ULID spec has problems like "monotonic ID" which is just a counter, entirely breaking the universal thing.
- RobertRoberts 4y ago
  From my experience this is only triggered when generating something like a thousand IDs a second (or more?), something I never run into in the systems I work on. Since _every_ system has a down side or limitation, I am perfectly happy with ULID's flaws. Why should there be disdain or dismissal of a system that solves many people's problems?

tomasreimers 4y ago

Finally! I have a question I've been dying to ask for some time. Most of the time, when I hear people talking about UUIDs being better than big ints, it comes down to big ints leaking data (how many users / posts / comments your site has) and letting an attacker fetch sequential entries (user id 4 works, now try 5). This is even the reasoning in the supabase article. While ULIDs don't reveal the next entry, they do leak data (either creation date or number of entries, as all ULIDs are either prefixed with physical time or logical time). Why don't we just encrypt / decrypt IDs when going over the wire (most API frameworks even have native methods to transform different types of data)? It suffers from neither issue above, is natively supported by API frameworks, and any time used on compute will be dwarfed by network latency. Is this already a pattern and I just don't know about it? EDIT: ahh, below they list one advantage of UUIDs / ULIDs which is you can generate client side. That is reasonable.

andy_ppp 4y ago

Great username, however ULIDs look good and I’d consider using them simply because they solve the problems UUID v7 attempts to solve while being considerably better in some regards and slightly worse in others. I think for my next project I’ll try them instead of UUIDv4. In the end support for something this simple and complete isn’t something I’d have big concerns about.

mirzap 4y ago

Thank you for posting pg_idkit. For months I was searching something like it. Supabase doing great things as well. They have couple others great PG extensions.