There’s also http://gh.peabody.io/uuidv6/ as an alternative to ULID, but again it’s only proposed but not yet an officially accepted standard.

Generally however I’d suggest not needing to sort by (only) the primary id. You’re talking about articles. Articles usually have a published at date(time), so sorting should happen by that. To achieve a stable sort you can use the primary id as secondary sorting column.

You can simply use ordering by multiple columns: [:inserted_at, :id]. If inserted_at column is the same then ordering by id will be applied, so you will always have strict order.

Something to consider: the order of these things sounds important. Is it possible to update that order after inserting the records? Consider materializing that order with something like a position column.

I don’t know your exact use case, but ULIDs could be worth looking into as an alternative to UUIDs. They’re essentially lexicographically sortable UUIDs that embed both a Unix timestamp and random data.

You still only get millisecond precision, but you end up with a stable ordering over them because of the random segment.

ULIDs are a relatively new idea, and library support isn’t great in all languages. You also do leak timing info through the ULID, which isn’t always desirable.

There may be other drawbacks, but I’m not an expert, sorry.