Do you have any information where querying these UUIDs would be relevant and changing would benefit performance? As far as I can see, these UUIDs are not stored anywhere, and only used for OTEL traces, and event IDs (which needed something unique).

Other uses are as part of tests, which just needed a sample value.

I think v7 is even (although very marginal) slower;

package main

import (
	"testing"

	"github.com/google/uuid"
)

func BenchmarkUUIDv4(b *testing.B) {
	b.ReportAllocs()
	for range b.N {
		uuid.NewString()
	}
}

func BenchmarkUUIDv7(b *testing.B) {
	b.ReportAllocs()
	for range b.N {
		uuid.Must(uuid.NewV7()).String()
	}
}

BenchmarkUUIDv4-10    	 3664420	       320.2 ns/op	      64 B/op	       2 allocs/op
BenchmarkUUIDv7-10    	 3247585	       370.2 ns/op	      64 B/op	       2 allocs/op

@thaJeztah Good point. The main thing I'm looking for is UUIDv7s for event ids. Reason being we store these in our Postgres db after processing incoming webhooks.

If you check out the links I shared above you'll see that insertion performance with Postgres is 30% better with UUIDv7s vs UUIDv4s (i.e. more or less as fast as bigints):

The only reason I replaced all occurences with the v7 logic was for consistency. But another option could be leaving everything as is and just using v7s for event IDs? Since they're probably the only thing people store in their own backends.

Oops sorry for the delay, I missed your last comment!

Reason being we store these in our Postgres db after processing incoming webhooks.

Thanks, with that context, this change makes a lot more sense to me! Sorry if my earlier comment came across bad; mostly trying to avoid code changes for "theoretical cases" - I've run into those in various projects, so context matters!

Based on this, I think the change looks reasonable.

Some quick digging; if my information is correct, UUIDv7 has less entropy (62-74 bit vs 122 bit) - not sure if that matters here, but just in case it's a concern.

The only reason I replaced all occurences with the v7 logic was for consistency. But another option could be leaving everything as is and just using v7s for event IDs? Since they're probably the only thing people store in their own backends.

It's probably fine to keep the changes as-is, even if not strictly needed for all. The only concern I had was the utility package (but mostly from a perspective that this project used to have a uuid package, that others found, and which now became a public API used externally). This PR keeps it inside internal/ so that should not be a concern, other than "it may be tempting for someone to open a PR to make it public", but that's a future concern 😂

cc @milosgajdos - in case you have thoughts

Thanks, with that context, this change makes a lot more sense to me! Sorry if my earlier comment came across bad; mostly trying to avoid code changes for "theoretical cases" - I've run into those in various projects, so context matters!

No worries at all! Totally understand.

Some quick digging; if my information is correct, UUIDv7 has less entropy (62-74 bit vs 122 bit) - not sure if that matters here, but just in case it's a concern.

Yeah there's a bit less entropy because of the timestamp data but they're still considered unique. The chance of collisions is infinitesimally small. The aim with v7 was to solve the index performance issues while maintaining uniqueness. Here's a case study which outlines the real world benefits. A couple of years old but a good read: https://buildkite.com/resources/blog/goodbye-integers-hello-uuids/

Actually @binaryfire mind squashing commits, please

Actually @binaryfire mind squashing commits, please

Ah, yes; LGTM after it's squashed

Commits have been squashed.

@thaJeztah PTAL