UUID v7 Java: Time-Ordered Identifiers on the JVM

Library options

java-uuid-generator (JUG) from FasterXML is the established choice and supports every version:

// com.fasterxml.uuid:java-uuid-generator
NoArgGenerator gen = Generators.timeBasedEpochGenerator();
UUID id = gen.generate();   // v7

uuid-creator by f4b6a3 is the other common option, with a simpler API — UuidCreator.getTimeOrderedEpoch(). Both produce standard v7 values that interoperate with any other implementation.

Reuse the generator instance. Creating one per call re-initialises the random source and gives up the monotonicity guarantees within a millisecond.

Why v7 for keys

v4 is random, so each insert lands in a random position of the B-tree index. Pages split constantly, the working set does not fit in cache, and write throughput degrades as the table grows.

v7 starts with a 48-bit millisecond timestamp, so new rows cluster at the right edge of the index — the same access pattern as an auto-increment key, while keeping client-side generation.

Persisting them

With JPA, map to the native type where the database has one:

@Id
@Column(columnDefinition = "uuid")   // PostgreSQL native
private UUID id;

On MySQL use BINARY(16) with a converter rather than CHAR(36) — it halves storage and keeps index entries compact. Do not let Hibernate default to a varchar column for a UUID key.

The caveat

v7 embeds creation time, so anyone holding an identifier learns when the record was created, and two identifiers reveal the interval between them. For internal keys that is fine; for public identifiers it may leak business information such as signup volume.

Where that matters, keep v7 internally and expose a separate opaque identifier externally.