Skip to main content
Back to Numbers generators

Numbers

UUID v7-Style Generator

Used by developers, writers, and creators worldwide.

A UUID v7-style generator creates time-ordered identifiers with a 48-bit millisecond timestamp in the most-significant bits, followed by 62 bits of random data — making each ID globally unique and chronologically sortable. Unlike UUID v4, which scatters records randomly across a B-tree index, v7-style IDs always insert near the tail, keeping write performance close to auto-increment without sacrificing global uniqueness. This matters in PostgreSQL, MySQL, and SQL Server where random UUIDs cause index fragmentation and page splits. Teams replacing integer primary keys in multi-region or distributed systems increasingly choose v7 over v4. Set the count, generate a batch, and paste the IDs directly into seed scripts, migrations, or trace logs.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  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

  • •Seeding a PostgreSQL staging database with 100 time-ordered primary keys to test cursor-based pagination
  • •Generating correlation IDs for OpenTelemetry traces across microservices so spans sort by creation time
  • •Replacing auto-increment IDs in a Prisma schema migration without adding a separate created_at index
  • •Assigning sortable identifiers to Kafka event messages so consumers can replay them in emission order
  • •Populating Postman environment variables with realistic UUIDs for integration tests against a REST API

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 for database primary keys

UUID v4 is fully random, so inserts land at arbitrary positions in a B-tree index, causing page splits and write amplification over time. UUID v7 puts a millisecond timestamp in the first 48 bits, so new rows always append near the end of the index — similar to auto-increment behavior. For high-write tables in PostgreSQL or MySQL, v7 can meaningfully reduce index bloat.

can you extract a timestamp from a uuid v7 id

Yes. Strip the hyphens, take the first 12 hex characters, and parse them as a big-endian integer — that value is the Unix timestamp in milliseconds. This means you can recover approximate record creation time from the ID itself, without storing a separate created_at column.

is uuid v7 safe to use in public urls or api responses

Generally yes, but the timestamp prefix reveals roughly when a resource was created, which is acceptable for most API IDs. If hiding creation time is a requirement — for example, on user-facing resource IDs — UUID v4 or an opaque token is a better fit. For internal service IDs, event correlation, and trace headers, v7's timestamp is usually an asset rather than a liability.