UUID v7 keeps the global uniqueness model developers like about UUIDs, but places a Unix millisecond timestamp at the front. Newer IDs sort near newer IDs, which is helpful in storage engines and log pipelines.
Key takeaways
- Designed for better chronological sorting than UUID v4.
- Useful for write-heavy tables, events and observability data.
- Creation time is partly visible, so avoid it when that leak matters.
Why teams are moving to UUID v7
Random identifiers are convenient, but databases often prefer ordered inserts. UUID v7 is a practical middle ground: it can be generated without a central sequence, while still grouping new values by creation time.
That ordering makes debugging easier too. When support engineers scan logs or exported rows, v7 identifiers tend to move in the same direction as the timeline.
What is inside UUID v7
A UUID v7 starts with a Unix timestamp in milliseconds, followed by random bits and the required version and variant markers. The timestamp is not meant to be a perfect audit record, but it is enough to make the identifier naturally sortable.
018f2f7a-07b2-7d6e-9c37-43e1577b8b44
^^^^^^^^^^^^^
time-oriented prefixGood UUID v7 use cases
Choose UUID v7 for primary keys in new systems when you want UUID-style uniqueness without the storage pattern of purely random UUID v4 values. It is also a strong fit for event IDs, trace records, audit entries and inbox/outbox tables.
If your application exposes IDs publicly and timestamp leakage is harmless, v7 is usually easier to operate than a random ID at high write volume.
When not to use UUID v7
Avoid UUID v7 when the creation time itself is sensitive. For example, a public identifier that reveals when a user account, invoice or private case was created may be more information than you want to share.
If that timing leak matters, use UUID v4 or issue an opaque public ID while keeping the ordered primary key private.