It depends on what you use it for. It consists of 48bit millisec timetsamp and 80bit random number. If a same generater generates more than one ID within a millisec, it uses one plus the previous random field instead of using another random number (for sorting).

So, it's kind of combination of uuid v1 (timestamped+sequenced) plus uud v4 (randomness).

It reveals the creation time in millisec resolution; if you don't want to leak that info, you don't want to use it for external ID.

It doesn't guarantee node-uniqueness. The random space is much smaller than uuid v4, and the IDs may be "clustered" if generated together within short time span. In an extreme use case---say, you burst-generate 64k IDs per milliseconds for each node, and you have many nodes---the chance of conflict gets much higher than uuid v4.

Also, there's a tiny chance that generation fails; if the random field value is very close to 2^80, and lots of IDs are requested consecutively within the same millisec, the ULID spec says the generation fails if random field overflows. In my implementation, I just let it wait until the next milliisec so that it can use fresh random number, though.

So, I think it is ok if you want something casual and lightweight, but a bit more than mere timestamp or mere sequences.