How does it compare to ULID? about xid HOT 5 OPEN

IDs from the same second have a local monotonic incrementing random inited counter, so they will still sort well when generated on the same machine/process.

from xid.

ULID requires locking if you need to use it concurrently.

from xid.

many years later, I think another major difference compare to ULID is xid is only up to 1 second precise, meaning sorting is only possible within the same second, whereas ULID is up to millisecond precise.

from xid.

For concurrency ULID requires a lock while xid uses an atomic counter as a workaround. Depending on the application, this can be a factor. Conciseness is another.

from xid.

xid seems relatively better if the priority is conciseness, indexing-performance and zero-configurability. But I am not too sure if the locking argument holds true @rs :

ULID requires locking if you need to use it concurrently.

According this comparison of Golang ID packages actually https://github.com/oklog/ulid also achieves fast lock-free concurrent ULID generation

Besides millisecond precision, ULID also enjoys broader support due backward compatibility with UUID columns e.g. Cockroach DB has a builtin function to generate ULIDs for PKs

For a distributed DB like Cockroach DB with xid generated in the application layer over distributed containers / serverless functions sharing a DB cluster, @rs are there any reasons you would still recommend xid over ULID all things considered, especially when there's no guarantee that the xid will be generated on the same machine/process?

from xid.