Numbers

UUID v7-Style Generator

UUID v7-style identifiers solve one of the biggest pain points with traditional UUIDs: random ordering that fragments database indexes and slows down queries. A UUID v7-style generator produces IDs that begin with a millisecond-precision Unix timestamp, followed by random bits to guarantee uniqueness. The result is an identifier that looks like a standard UUID but sorts chronologically, so your newest records always land at the end of a B-tree index rather than scattered randomly throughout it. This matters more than it sounds. Fully random identifiers like UUID v4 cause page splits and index bloat in databases such as PostgreSQL, MySQL, and SQL Server. Time-ordered UUIDs reduce write amplification and keep sequential inserts fast, which is why teams migrating from integer auto-increment to globally unique IDs increasingly reach for v7 over v4. The format is also specification-aligned. The IETF RFC 9562 draft formalizes UUID v7 with a 48-bit timestamp in the most-significant bits, followed by version and variant fields, then 62 bits of random data — giving you roughly 2^62 unique IDs per millisecond. This generator produces IDs in that structure, making them compatible with any system that accepts standard UUID strings. Whether you are seeding a local database with test data, prototyping a distributed event pipeline, or just need a batch of chronologically ordered unique identifiers to paste into a schema migration, this tool generates up to any count you need in one click.

How to Use

  1. Set the count field to the number of UUID v7-style IDs you need, from 1 up to your desired batch size.
  2. Click the generate button to produce a list of time-ordered UUIDs stamped with the current millisecond.
  3. Copy individual IDs by clicking them, or select all output text and paste the full list into your database seed file, migration script, or test fixture.
  4. Re-click generate at any time to produce a fresh batch; each click captures a new timestamp so new IDs will always sort after the previous batch.

Use Cases

  • •Generating primary keys for PostgreSQL tables to avoid index fragmentation
  • •Creating correlation IDs for distributed tracing across microservices
  • •Seeding test databases with time-ordered records for pagination testing
  • •Assigning identifiers to IoT sensor events that must replay in order
  • •Building event-sourced systems where event order must be derivable from ID
  • •Replacing auto-increment IDs in multi-region databases without coordination
  • •Labeling batch job runs so logs sort by execution time automatically
  • •Generating IDs for audit trail entries in compliance-sensitive applications

Tips

  • →Generate IDs in two separate clicks — the second batch will always sort after the first, which is useful for testing pagination or cursor-based APIs.
  • →When seeding a database, paste v7 IDs directly as primary keys; their chronological order will pre-sort your seed rows the same way production data would arrive.
  • →Avoid storing UUID v7 as a VARCHAR if you can use a native UUID type — binary storage halves the index size and speeds up joins significantly.
  • →If you need to verify the embedded timestamp, paste the first 12 hex characters (no hyphens) into a hex-to-decimal converter, then divide by 1000 to get Unix seconds.
  • →For multi-table schemas, generate all IDs for a single import in one batch so related records share a tight timestamp range, keeping foreign key lookups on the same index pages.
  • →UUID v7 IDs generated within the same millisecond differ only in their random suffix — if strict ordering within a millisecond matters, add a monotonic counter column alongside the ID.

FAQ

What is the difference between UUID v4 and UUID v7?

UUID v4 is entirely random — all 122 non-fixed bits are random, so IDs have no inherent order. UUID v7 places a 48-bit millisecond timestamp in the most-significant bits, followed by random bits. This means v7 IDs sort chronologically, which dramatically reduces index fragmentation in databases that store them as primary keys.

Are UUID v7 IDs truly unique or can they collide?

Collisions are astronomically unlikely. Even within the same millisecond, each ID contains 62 bits of random data, giving over 4.6 quintillion possible values per millisecond per node. In practice, you would need to generate billions of IDs per millisecond from a single source before collision probability becomes measurable.

Can I use UUID v7 as a primary key in PostgreSQL or MySQL?

Yes, and it is one of the best reasons to use v7. Store it as a UUID type in PostgreSQL or a CHAR(36) or BINARY(16) in MySQL. Because new IDs always have higher timestamp values, inserts append near the end of the index rather than splitting random pages, keeping write performance close to auto-increment behavior while remaining globally unique.

Is UUID v7 an official standard?

UUID v7 is defined in RFC 9562, published by the IETF in May 2024. It supersedes RFC 4122, which only defined versions 1 through 5. The v7 format specifies a 48-bit big-endian millisecond timestamp, a 4-bit version field set to 7, a 2-bit variant field, and 62 bits of random data — totaling 128 bits in the familiar hyphenated hex string format.

How does UUID v7 compare to ULID or KSUID?

All three are time-ordered unique identifiers, but UUID v7 wins on compatibility — it fits the standard UUID format, so no schema or driver changes are needed if you already use UUID v4. ULID uses a different encoding (Crockford Base32) and KSUID has a coarser timestamp. UUID v7 is the best drop-in replacement for v4 in existing UUID-native stacks.

Can I extract the creation timestamp from a UUID v7 ID?

Yes. The first 48 bits (the first 12 hex characters, minus the hyphen) encode the Unix timestamp in milliseconds. Strip the hyphens, take the first 12 hex characters, convert to an integer, and you have the Unix millisecond timestamp. This makes UUID v7 useful for lightweight event sequencing without storing a separate created_at column.

How many UUID v7 IDs can I generate with this tool?

Set the count field to however many you need and click generate. The tool produces a list of IDs you can copy in bulk. For large-scale production use you would generate IDs in application code using a library, but this generator is useful for seeding test data, schema migrations, or any scenario where you need a ready-made batch immediately.

Are these IDs safe to expose publicly in URLs or APIs?

Mostly yes, with one caveat. The timestamp prefix leaks the approximate creation time of a resource, which is usually fine for technical IDs but could be a concern if you need to hide when a record was created. If creation time is sensitive, UUID v4 or an opaque token is more appropriate. For typical API resource IDs the tradeoff favors v7.