Every value comes from crypto.getRandomValues(), the browser's cryptographically secure random source — not Math.random(), which is predictable and must never be used for identifiers that need to be unguessable. Nothing is transmitted; you can disconnect and keep generating.
v4 is 122 random bits. It leaks nothing about when or where it was created, and collisions are not a practical concern — you would need to generate about 2.7 × 1018 of them before a 50% chance of one collision.
v7 puts a 48-bit millisecond timestamp in the high bits, so the values sort chronologically as strings. That single property makes an enormous difference as a database primary key.
A v4 UUID as a clustered primary key is close to a worst case. Each insert lands at a random point in the index, so pages split constantly, the working set is effectively the entire index rather than the recent end of it, and write throughput degrades badly as the table grows. On SQL Server with a clustered uniqueidentifier, or MySQL InnoDB where the primary key is the clustering key, this is a well-documented performance trap.
v7 inserts land at the end of the index, the way an auto-incrementing integer does — while keeping the properties people choose UUIDs for: generatable client-side, no coordination between services, no sequence to leak row counts.
The tradeoff is that a v7 embeds its creation time, readable by anyone who has the value. If a UUID is exposed publicly and the creation time is sensitive, use v4.
uuid in PostgreSQL, BINARY(16) in MySQL. As CHAR(36) you are paying more than double the storage and index size for no benefit.Guid.ToString("B") use them. Almost nothing else does.We do managed IT, networking and security for businesses across Central Oregon.
Managed IT Services Call 541-508-8797