Fixing Uuidv7 (for Database Use-Cases)
Posted3 months agoActive3 months ago
brooker.co.zaTechstory
calmpositive
Debate
20/100
Uuidv7Database DesignDistributed Systems
Key topics
Uuidv7
Database Design
Distributed Systems
The article discusses issues with UUIDv7 for database use-cases and proposes fixes, sparking a discussion on the trade-offs between different UUID versions and database indexing strategies.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
20m
Peak period
1
0-2h
Avg / period
1
Key moments
- 01Story posted
Oct 22, 2025 at 2:12 PM EDT
3 months ago
Step 01 - 02First comment
Oct 22, 2025 at 2:32 PM EDT
20m after posting
Step 02 - 03Peak activity
1 comments in 0-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 23, 2025 at 1:33 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45673005Type: storyLast synced: 11/17/2025, 9:11:23 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I'd kind of be interested in an ID that does combines an autoincrement prefix with a random suffix. Every ID would be unique and monotonically increasing due to the autoincrement and the random suffix would make it unguessable (or less guessable, depending on the number of bits used). It's an odd choice for a UUID, which usually worrys about decentralized ID generation, but so many smaller apps use UUIDs with a single central postgres database...
These kinds of experiments are well suited to UUIDv8.