While UUID4 can be good for UserID. Sometimes, to avoid having a second index in the DB, ULID is another good option; As not only it supports some of the features of UUID4 of uniqueness, it is also sortable.
The part that was last touched in 2019 is the spec + homepage. By this measure, UUID was last touched in 2005 (if we count RFC 4122).
Most ULID implementations are still actively maintained and people are still using it in production. Most implementations also have liberal license like MIT so no, you should not worry about the GPL spec (unless you plan to distribute the spec with your app).
Nice! I just hadn't seen it referenced anywhere before - the last big ID wave I can remember was the swath of content about moving to snowflake style IDs
ULID leaks information about when the user was created (while serial IDs leaking the order in which users were created and their cardinality).
I'm using ULIDs for the cases when the entity is publicly orderd by time: any timestamped event, e.g. a chat message, a log entry, or a sensor measurement/metric.
But need to be careful that the timestamp resolution is detailed enough.
Also, while ULID might be good for optimizing RDBMS indexes, it might create hotspots in NoSQL K/V stores (i.e. all entities will be created on the same node in the cluster).
> ULID leaks information about when the user was created
How often is this really a bad thing? Are you worried about someone enumerating the entire space of possible ULIDs for every millisecond without ever rate-limiting them? Not many people are building anonymous, privacy-first websites and there's plenty of other ways to determine when a user first started using the site regardless.
Also curious because I don't actually know: If a format spec is GPL, does that encumber implementations of said spec?
0: https://github.com/ulid/spec