# Fixing UUIDv7 (for database use-cases)

DevFeed: [Fixing UUIDv7 (for database use-cases)](<https://devfeed.tech/articles/fixing-uuidv7-for-database-use-cases-12580.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2025/10/22/uuidv7.html>)

Author: Marc Brooker

Published: 2025-10-22T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Security](<https://devfeed.tech/topics/security.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [cryptographic](<https://devfeed.tech/tags/cryptographic.md>), [database](<https://devfeed.tech/tags/database.md>), [datacenters](<https://devfeed.tech/tags/datacenters.md>), [performance](<https://devfeed.tech/tags/performance.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

The article examines UUIDv7 for database use cases, explaining how time ordering can improve index locality, insertion performance, and cache effectiveness while introducing concerns about timestamp leakage, reduced entropy, correlated behavior, and hot spotting. It proposes modifying UUIDv7 with a keyed hash, a tunable entropy parameter, and an infrastructure-specific identifier to balance locality with ID distribution.

## Source excerpt

Fixing UUIDv7 (for database use-cases) How do I even balance a V7? RFC9562 defines UUID Version 7. This has made a lot of people very angry and been widely regarded as a bad move1. More seriously, UUIDv7 has received a lot of criticism, despite seemingly achieving what it set out to do. The legitimate criticism seems to be on a few points. V7 UUIDs: Leak information (namely the server timestamp). Are a bad choice for cases where security or operational requirements require UUIDs that are hard to guess, because they have less entropy. Introduce correlated behavior between datacenters, regions, and installations of applications, increasing the probability of triggering bugs across failure boundaries. Are hard to present in UIs, because the E6EE7F40... format doesn't work, because of deterministic first digits. Before thinking about how we might fix these issues, let's understand why folks are drawn to UUIDv7. Most of the use-cases I see are related to increasing database insert performance. To quote the RFC: Time-ordered monotonic UUIDs benefit from greater database-index locality because the new values are near each other in the index. As a result, objects are more easily clustered together for better performance. The real-world differences in this approach of index locality versus random data inserts can be one order of magnitude or more. This effect is very real. Random DB keys like UUIDv4 destroy spatial locality (as I've written about before), making database caches less effective, almost always reducing insert performance, and reducing query performance where queries have substantial temporal locality. The slight upside to this is that they also avoid hot spotting in distributed or sharded architectures. Can we both have good insert performance and avoid the downsides of UUIDv7? Yes, I believe we can. Let's keep the overall format from the RFC: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+