UUID v4 vs v7
Hi,
I had a model which primary key was type of
long and it was used as cursor for pagination. This way I could simply do the following LINQ query: query.Where(l => l.Id >= queryParams.Cursor).
I switched from long to Guid and I think this is no longer a good solution.
Guid.NewGuid() generates a v4 UUID which is totally random. Surprisingly my query still works, and entities are in order, but that must be just a coincidence.
What if I used v7 UUIDs? Since it is time based, would the cursor pagination function correctly?6 Replies
Can't you paginate by, say, time created?
I wouldn't count on UUIDs being sequential in general
That is a good idea. Thanks
is there a reason you switched to GUIDs? that's generally recommended against for database keys because of the potential performance issues
I switched because the performance of the UUID 7 in Postgres is the same as an incremented value. A detailed benchmark can be seen here: https://ardentperf.com/2024/02/03/uuid-benchmark-war/
The only downside is that it takes up a lot of space
Jeremy
Ardent Performance Computing
UUID Benchmark War
This month’s PGSQL Phriday #015 topic is about UUIDs, hosted by Lætitia Avrot. Lætitia has called for a debate. No, no, no. I say let’s have an all-out war. A benchmark war. I have deci…
but what advantage does it give you over a regular sequential ID
In my case nothing, since I am not working in distributed environment. It is just a hobby project, but I like to try out new concepts