UUIDv7 Generator (Time-Ordered)
Generate UUIDv7s — the newest UUID variant standardized in RFC 9562. UUIDv7 packs a millisecond Unix timestamp into the leading bits, making generated IDs naturally sortable by creation time. That property makes them ideal for B-tree indexed database primary keys (no index fragmentation like UUIDv4), distributed systems (timestamp built-in, no separate created_at needed), and any context where time ordering plus uniqueness matters.
UUIDv7 vs other versions
| Version | Time-ordered | Best for |
|---|---|---|
| UUIDv4 | No (fully random) | Public IDs where order leaks info |
| UUIDv7 | Yes (ms timestamp) | Database primary keys, distributed IDs |
| UUIDv1 | Yes (older format) | Legacy systems; less private than v7 |
| ULID | Yes (Crockford-base32) | Non-UUID time-ordered IDs |
How to use the UUIDv7 Generator (Time-Ordered)
Set count, click Generate. Each UUIDv7 packs the current millisecond timestamp into the first 48 bits, followed by 12 bits of random data (with the v7 version bits set), then 62 more bits of random data. The result is a perfectly normal-looking UUID that's sortable by creation time.
About UUIDv7 Generator (Time-Ordered)
RFC 9562 (May 2024) standardised three new UUID versions: v6, v7, and v8. UUIDv7 is the version most teams care about: it solves the "UUIDv4 is bad for database indexes" problem by making the leading bits monotonically increasing with time. A B-tree primary key built on UUIDv7s grows in append-only fashion (no random page splits), giving you UUID-style uniqueness with sequential-key performance.
Common use case: replace auto-incrementing integer primary keys with UUIDv7. You get global uniqueness (no central allocator), good index locality (inserts go to one end of the B-tree), and a built-in creation timestamp (extract the first 48 bits, divide by 1000, you have a Unix timestamp). Postgres 17 has native UUIDv7 generation; MySQL and SQLite need application-level generation, which is exactly what this tool does.
Common use cases
- Database primary keys — replace UUIDv4 PKs that've caused index bloat.
- Distributed event IDs — generate unique event IDs without coordinating, naturally sorted by time.
- Log correlation IDs — UUID format that lets you sort by time.
- Migration testing — generate a few hundred UUIDv7s for load-testing your new schema.
Frequently asked questions
Will UUIDv7 collide?
Is it backward compatible with UUIDv4 columns?
4 for v4, 7 for v7.