--- title: UUIDv7 doesn't have the properties you think it does description: UUIDv7 does not strictly provide the monotonic ordering, accurate timestamps, or unguessability that most blog posts tout. RFC 9562 allows implementations to... canonical: https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: UUIDv7 doesn't have the properties you think it does | daily.dev og:description: UUIDv7 does not strictly provide the monotonic ordering, accurate timestamps, or unguessability that most blog posts tout. RFC 9562 allows implementations to... og:url: https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz og:image: https://api.daily.dev/og/posts/jjBOk9CZZ.png og:image:alt: UUIDv7 doesn't have the properties you think it does og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # UUIDv7 doesn't have the properties you think it does **[Hacker News](https://daily.dev/sources/hn)** · 8 min read · 0 upvotes · 0 comments ## Summary UUIDv7 does not strictly provide the monotonic ordering, accurate timestamps, or unguessability that most blog posts tout. RFC 9562 allows implementations to alter the embedded timestamp, so it can drift far from the actual creation time. In Python's standard library implementation, setting the system clock back one hour while under load causes the timestamp to race ahead of real time, with the example's deltas reaching about 3,995 seconds. Implementations that were inspected did not persist the last-used timestamp, so they can generate out-of-order IDs after a process restart following a clock jump backwards. The only property UUIDv7 appears to strictly provide is uniqueness and collision resistance. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does the timestamp embedded in a UUIDv7 always match when the record was created? No, RFC 9562 explicitly allows implementations to alter the timestamp field so it is not strictly derived from the system clock. PostgreSQL's own documentation for uuid_extract_timestamp warns the extracted timestamp is not necessarily exactly equal to the generation time. In some implementations, like Python's standard library, the embedded timestamp can race arbitrarily far ahead of real time after a clock rollback under load. _Anyone relying on UUIDv7 timestamps for auditing should weigh this drift risk before trusting daily.dev's developer coverage of ID design._ ### Why does Python's uuid.uuid7() generate timestamps that run far ahead of the system clock? If the system clock jumps backward and generation load exceeds about one ID per millisecond, Python's uuid7() refuses to let the embedded timestamp decrease, so it keeps incrementing it instead. This creates a runaway effect: after setting the clock back one hour, deltas between the embedded timestamp and real time grew from roughly 3,695 to 3,995 seconds within a few iterations, increasing without bound under sustained load. _Developers debugging clock-related ID bugs can keep tabs on these edge cases through daily.dev's backend and database coverage._ ### Are UUIDv7 IDs guaranteed to be generated in strictly increasing order? No, UUIDv7 does not strictly guarantee monotonic ordering, even on a single node. An implementation using only a millisecond timestamp without a counter can trivially produce out-of-order IDs within a simple for loop, and across distributed nodes, clock synchronization limits make strict time-ordering mathematically unachievable, a problem known since Lamport's work in the 1970s on logical clocks. _Teams choosing an ID scheme for sortable records can track these monotonicity caveats via daily.dev before committing to UUIDv7._ ## Community take How the wider developer community reacted, aggregated from 3 discussions and 101 comments across hackernews, lobsters (as of 2026-10-23). **TL;DR:** Most agree the article's specific technical findings are accurate but see it as nitpicking since nobody actually relies on UUIDv7 for strict monotonicity, precise timestamps, or unguessability — the real and still-valid reason to use it is improved B-tree index locality from roughly-sorted keys. **Sentiment:** 20% positive · 60% mixed · 20% skeptical **The case for** - The core argument (timestamps can drift, ordering isn't guaranteed, implementations vary) is technically correct and worth knowing. - Highlights real footguns like clock jumps and process restarts causing out-of-order IDs. - Useful reminder that extracted timestamps shouldn't be trusted as exact creation times. **The pushback** - Many feel the post nitpicks properties nobody actually relied on — the real benefit (write locality / reduced index fragmentation) only needs rough ordering, not strict guarantees. - Some argue the framing is clickbait-y, a 'neg' that overstates how big a problem this is in practice. - Several think using UUIDs at all (vs serial/integer keys or hybrid logical clocks) sidesteps most of the discussed issues. - Disagreement over whether the timestamp component is even meant for anything beyond sharding/indexing, since the spec never promised strict monotonicity. **By community** - hackernews (mixed): A large sprawling thread split between agreeing the technical caveats are real and arguing the post nitpicks properties nobody actually depended on, with much tangential debate about UUID vs serial keys. - lobsters (skeptical): Commenters, including the author, largely argue the post undersells the actual main benefit (B-tree write locality) which doesn't require the strict properties being critiqued. **Hottest debate:** Whether UUIDv7's real value (index/write locality from rough time-ordering) was ever meant to require the strict monotonicity/timestamp accuracy the post criticizes, or whether the post is attacking a strawman. **Open questions** - How should systems that truly need monotonic, idempotent IDs implement them (hybrid logical clocks, server-side counters, UUIDv5 determinism) instead of relying on UUIDv7? - At what point does leaking approximate creation time via UUIDv7 become a meaningful privacy/business-intelligence risk? **Highlights** > Author here, this comment sums my position up well, thanks! There was a longer version of this post that talked about Postgres in more detail, but I trimmed it out. Using UUIDv7 for Postgres B-tree write locality does not require strictly monotonic IDs, so I think it is a good fit. Postgres is interesting to talk about because the UUID could be generated by Postgres itself or it could be generated by a (trusted) client using any UUIDv7 implementation. That sort of distributed generation makes it easier to see how offset clocks could impact monotonicity. I also wanted to be careful as there are many Postgres-compatible databases which use distributed storage. Those may see worse write performance if UUIDv7 causes all the writes end up on a single shard, but it's implementation specific and I'd want to benchmark it. Vendors encourage developers to think of those as Postgres, but they are only Postgres-compatible and they have different low-level trade offs. > — [robalex on lobsters · 6 points](https://lobste.rs/s/kcyzco/uuidv7_doesn_t_have_properties_you_think#c_h1jcgi) > Kind of funny title since I didn’t think UUIDv7 had any of the properties being disputed here. The reason to use UUIDv7 is because it reduces the space over which the UUID can cover at a given time, which improves write clustering. They don’t need to be strictly ordered for this, just “good enough”. I hope to god no one is actually using the timestamp portion to replace an “updated at” timestamp but I suspect I’ll be disappointed. > — [kentm on hackernews · 1 comments](https://news.ycombinator.com/item?id=50213916) > It doesn’t have anything to do with indexing more than one thing. The issue with truly random IDs is that inserts are scattered throughout the B-tree index, which cause page splits, fragmentation, and poor cache locality. Using a timestamp prefix makes new IDs sequential, so inserts tend to land near the end of the index, which avoid all the B-tree trashing and improve write performance. > — [debazel on hackernews · 1 comments](https://news.ycombinator.com/item?id=50214401) > UUIDv7 is not that useful. I'm still using mostly UUIDv4 and UUIDv5. I'm leaning increasingly heavily on v5 for its determinism which is extremely important for IDs. I would sacrifice every other property to get determinism. You can't have idempotency without determinism and you can't get reliability without idempotency. Once you factor in failure and retry scenarios under concurrency, you often need ID determinism. In the rare cases I don't want determinism, I prefer to go all-in on randomness. I prefer my IDs to be well spread out; it scales better, more predictable, less of a security liability (prefer not to have all data clustered in the same place)... Both UUIDv4 and UUIDv5 outputs are uniformly distributed. IMO this is a desirable property which is well worth a bit of additional compute. v7 feels like an optimization hack, and it comes at a cost. If you want to get the performance benefits of v7 with the determinism of v5, then you need to have essentially two IDs; the id (v7) and an idempotency key (which is essentially like a second ID you have to maintain; e.g. UUIDv5)... In the end, maintaining a UUIDv7 ID + idempotency key is less performant than just having a single UUIDv5 id which does both jobs for no extra effort... Not to mention, less maintainable and more complicated to use. > — [jongjong on hackernews](https://news.ycombinator.com/item?id=50216755) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50211746) · 100 points · 87 comments - [hackernews](https://news.ycombinator.com/item?id=50204322) · 5 points · 2 comments - [lobsters](https://lobste.rs/s/kcyzco/uuidv7_doesn_t_have_properties_you_think) · 41 points · 12 comments ## Similar posts on daily.dev - [UUID v4 vs v7, and what's inside a UUID](https://daily.dev/posts/uuid-v4-vs-v7-and-what-s-inside-a-uuid-buf3wbyzk) · Flavio Copes · 2 upvotes · 0 comments - [PostgreSQL 18's UUIDv7: Faster and Secure Time-Ordered IDs](https://daily.dev/posts/postgresql-18-s-uuidv7-faster-and-secure-time-ordered-ids-smvesvjbw) · Hashrocket · 42 upvotes · 0 comments - [The Time Traveler's Primary Key](https://daily.dev/posts/the-time-traveler-s-primary-key-x5yvsdpzm) · Planet PostgreSQL · 0 upvotes · 0 comments - [UUID v7 vs. ULID: Which Sortable ID Should You Choose?](https://daily.dev/posts/uuid-v7-vs-ulid-which-sortable-id-should-you-choose--xlgz26hfk) · Ruby Flow · 0 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#backend](https://daily.dev/tags/backend), [#postgresql](https://daily.dev/tags/postgresql), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"UUIDv7 doesn't have the properties you think it does","url":"https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz"},"datePublished":"2026-10-23T17:54:52.577Z","dateModified":"2026-10-23T23:56:35.896Z","description":"UUIDv7 does not strictly provide the monotonic ordering, accurate timestamps, or unguessability that most blog posts tout. RFC 9562 allows implementations to...","image":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","thumbnailUrl":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"python,backend,postgresql,distributed-systems","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"UUIDv7 doesn't have the properties you think it does"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/uuidv7-doesn-t-have-the-properties-you-think-it-does-jjbok9czz#faq","mainEntity":[{"@type":"Question","name":"Does the timestamp embedded in a UUIDv7 always match when the record was created?","acceptedAnswer":{"@type":"Answer","text":"No, RFC 9562 explicitly allows implementations to alter the timestamp field so it is not strictly derived from the system clock. PostgreSQL's own documentation for uuid_extract_timestamp warns the extracted timestamp is not necessarily exactly equal to the generation time. In some implementations, like Python's standard library, the embedded timestamp can race arbitrarily far ahead of real time after a clock rollback under load. Anyone relying on UUIDv7 timestamps for auditing should weigh this drift risk before trusting daily.dev's developer coverage of ID design."}},{"@type":"Question","name":"Why does Python's uuid.uuid7() generate timestamps that run far ahead of the system clock?","acceptedAnswer":{"@type":"Answer","text":"If the system clock jumps backward and generation load exceeds about one ID per millisecond, Python's uuid7() refuses to let the embedded timestamp decrease, so it keeps incrementing it instead. This creates a runaway effect: after setting the clock back one hour, deltas between the embedded timestamp and real time grew from roughly 3,695 to 3,995 seconds within a few iterations, increasing without bound under sustained load. Developers debugging clock-related ID bugs can keep tabs on these edge cases through daily.dev's backend and database coverage."}},{"@type":"Question","name":"Are UUIDv7 IDs guaranteed to be generated in strictly increasing order?","acceptedAnswer":{"@type":"Answer","text":"No, UUIDv7 does not strictly guarantee monotonic ordering, even on a single node. An implementation using only a millisecond timestamp without a counter can trivially produce out-of-order IDs within a simple for loop, and across distributed nodes, clock synchronization limits make strict time-ordering mathematically unachievable, a problem known since Lamport's work in the 1970s on logical clocks. Teams choosing an ID scheme for sortable records can track these monotonicity caveats via daily.dev before committing to UUIDv7."}}]} ```