Yes, but only on single machines, UUID and co are intended for distributed systems.

Although now I wonder if / how UUID v7 can do sequential keys on distributed systems. Mind you, on those systems "close enough" will probably be good enough, and sorting will be done by date instead of incremental ID.

You could also keep a global incremental index for that, assuming there's some authoritative server that has to be polled sequentially to get them.

Probably too much overhead when conflicting UUIDs are a few orders of magnitude less likely than the clients crashing from some random bug though.

So just prefix the node ID which is assigned when the node joins a swarm

How is that easier or better? Now you're letting your infrastructure details bleed into your database.

They should bleed into your database. The database is part of your infrastructure and it contains details like where to find the replicas and so on

Why? Tight coupling doesn't make things easier.

You’re complaining that the infrastructure details are bleeding into the intrastructure implementation?

Infrastructure details are bleeding into non-infrastructure implementation. Your database content is not an infrastructure implementation.

the content is not, but it can use a database function, such as CURRENT_TIMESTAMP or RANDOM() can it not?

I'm not sure what you're getting at. How are those connected to the topic? Those functions aren't infrastructure implementations either.

Ah but you see, UUIDs are web scale.

And by web scale, I mean they're too big to exchange by any offline channel.

It's 128 bits vs 64 bits - not really that much of a difference.

FWIW… we’re using UUIDv7s over BLE.

Should you, though? BLE itself uses UUIDs, but the ones it uses are in a shortened format just because the BLE frames are small and the protocol is not too fast.

Granted I've even used JSON over GATT so maybe I should keep my mouth shut :).

It’s for an auth use. And at least we’re using CBOR. But I get your point.