UUID v4 vs UUID v7: Which One Should You Generate?

UUID v4 and UUID v7 are both useful, but they optimize for different things.

UUID v4 is random. UUID v7 includes a Unix timestamp component and is designed to be time ordered.

UUID v4

Use UUID v4 when you want:

• Random identifiers
• Simple client-side ID generation
• Public IDs with no built-in timestamp
• Broad compatibility with older systems

The downside is ordering. Random IDs do not naturally sort by creation time and may be less friendly for some database indexes.

UUID v7

Use UUID v7 when you want:

• IDs that roughly sort by creation time
• Better database locality than random IDs
• Distributed ID generation without a central sequence
• Logs or events that benefit from time ordering

Because UUID v7 contains timestamp bits, do not use it when creation-time leakage is a problem.

Database and Privacy Tradeoffs

UUID v4 is excellent when you need a hard-to-guess public identifier. It does not reveal when the record was created, but random insertion order can make large database indexes less cache-friendly.

UUID v7 keeps the uniqueness benefits of UUIDs while making new IDs roughly time ordered. That can help indexes, event tables, audit logs, and append-heavy systems. The tradeoff is that the ID itself carries timing information, which may be sensitive for user accounts, private documents, or low-volume systems where creation time reveals business activity.

| Use case | Better default | | ------------------------------- | ----------------------------------- | | Public share IDs | UUID v4 | | Event logs | UUID v7 | | Database primary keys at scale | UUID v7, if supported by your stack | | Legacy integrations | UUID v4 | | IDs that must not reveal timing | UUID v4 |

Before switching an existing system to UUID v7, check database support, sorting behavior, and whether downstream services assume UUID v4 randomness.

For new projects, document the choice near the model or migration that creates the ID. Future developers should know whether the ID was chosen for privacy, compatibility, index locality, or event ordering.

Quick Answer

Choose UUID v4 for simple random IDs and broad compatibility. Choose UUID v7 when sortable, time-ordered identifiers are useful for databases, logs, or event streams.

Useful reference:

• RFC 9562: UUIDs