Earlier quoted context omitted.
> It seems like the only real use case for these timestamps is to get data from around the same time together. Yep. > A second is fine for that. Not when you're doing O(1k-1M) operations per second, it isn't!
I’d think that the locality would only matter at the scale of your query. I’m sure someone has queries with a window less than a second and so much traffic, but it seems niche enough to not optimize the standard for it. I could definitely be off. I work at a company that gets those levels of traffic but don’t deal with it directly.
For me the whole value prop for ULIDs is that they can be generated by any node in a distributed system without coordination, while roughly preserving time order. "Roughly" meaning: all IDs will be globally ordered at millisecond precision, subject to the accuracy of each node's system clock; and IDs from a specific node will be locally ordered, subject to the details of the monotonicity part of the ID generator. This is important for me, because most of the things I attach IDs to will happen many many many times per second.