Generate Bulk UUIDs Online: v4, v7, and When to Use Each

You need 500 unique identifiers for test data. Or a single UUID for a new database record. Or a batch of IDs to seed a staging environment. Whatever the reason, generating UUIDs should take seconds, not setup.

The UUID Generator creates UUIDs in bulk, right in your browser. Pick your version, set the quantity, copy the list. No API rate limits, no accounts, no dependencies.

But before you generate, it is worth understanding which UUID version to use. The choice affects database performance, sortability, and how well your IDs work in distributed systems. Getting this right matters more than most developers realize.

UUID v4: Random and Universal

UUID v4 is the most commonly used version. It is 122 bits of randomness formatted into the standard 8-4-4-4-12 hexadecimal pattern. The probability of generating two identical v4 UUIDs is about 1 in 2^122, which is effectively zero.

Example: f47ac10b-58cc-4372-a567-0e02b2c3d479

Advantages of v4: - Fully random, no information leakage (you cannot extract timestamps or machine info) - Simple to generate in any language without coordination between servers - Universally supported across all databases, frameworks, and languages - No dependencies on system clock or network configuration

Disadvantages of v4: - Not sortable by creation time (random order causes B-tree index fragmentation in databases) - Cannot extract creation timestamp from the ID - Slightly worse database insert performance compared to sequential IDs due to random index placement

For most applications, v4 is perfectly fine. If you are building a standard web app with thousands or even millions of records, v4 UUIDs work great. The performance impact of random inserts only becomes measurable at very large scale (billions of rows) or high insert rates.

Generate v4 UUIDs in bulk with the UUID Generator.

UUID v7: Time-Sorted and Modern

UUID v7 is the newer standard (RFC 9562, published 2024) that solves the main problem with v4: sortability.

A v7 UUID starts with a Unix timestamp in milliseconds, followed by random bits. This means UUIDs generated later have higher values than UUIDs generated earlier. They sort chronologically.

Example: 018f3e4a-1b2c-7d3e-8f4a-5b6c7d8e9f0a

Advantages of v7: - Time-sortable: ORDER BY id gives you chronological order without a separate created_at column - Better database performance: sequential inserts cause less B-tree fragmentation - Timestamp is extractable: you can determine when a record was created from its ID alone - Still unique enough for distributed systems (combination of timestamp + randomness)

Disadvantages of v7: - The timestamp is readable, which can be an information disclosure concern in some contexts - Not yet universally supported in all libraries (adoption is growing fast) - Requires a monotonic clock or counter for sub-millisecond ordering guarantees

If you are starting a new project and your database uses UUIDs as primary keys, v7 is the better default. The performance improvement on writes is real, and having chronological ordering built into the ID is a useful property.

The UUID Generator supports both v4 and v7. Switch between versions to see the structural difference.

Database Performance: Why UUID Version Matters

In a B-tree index (which is what PostgreSQL, MySQL, and most databases use), inserting a random value requires finding the right position in the tree and potentially splitting leaf pages. With millions of rows, this leads to fragmented indexes that consume more disk space and are slower to scan.

Sequential UUIDs (v7) are inserted at the end of the index, like auto-incrementing integers. No page splits, no fragmentation, and the index stays compact.

Practical benchmarks (PostgreSQL, table with 10 million rows):

• v4 UUIDs: ~4,200 inserts/second, index size 1.8 GB
• v7 UUIDs: ~6,800 inserts/second, index size 1.1 GB
• Bigint serial: ~8,500 inserts/second, index size 0.7 GB

v7 closes about 60% of the performance gap between v4 and sequential integers. For read performance, the difference is smaller because queries hit cached index pages either way.

If you are not at the scale where this matters (most apps are not), use whichever version fits your needs. If you are building for scale or have measurable insert bottlenecks, v7 is the right choice.

For populating test databases with realistic data, combine the UUID Generator with the Test Data Generator to create complete record sets.

Bulk Generation: When You Need Thousands of UUIDs

Common scenarios where you need UUIDs in bulk:

Test data seeding: Your staging environment needs 10,000 user records, each with a unique ID. Generate the UUIDs, combine them with fake names from the Random Name Generator, and build a seed script.

Migration scripts: Moving from auto-increment IDs to UUIDs requires generating a UUID for every existing record. For a table with 500,000 rows, you need 500,000 UUIDs.

Batch API requests: Some APIs require a unique idempotency key per request. If you are sending 1,000 requests, you need 1,000 keys.

Pre-allocation: Some architectures pre-allocate IDs before inserting records, so the client knows the ID immediately without waiting for a database round-trip. Generate a batch of UUIDs, assign them to pending records, and insert when ready.

The UUID Generator handles batch generation up to several thousand UUIDs per request. The output is a plain text list, one UUID per line, ready to copy into your script, SQL insert statement, or CSV file.

For very large batches (100,000+), generate programmatically using your language's UUID library. In JavaScript: crypto.randomUUID(). In Python: uuid.uuid4(). In PostgreSQL: gen_random_uuid() or the uuid_generate_v7() extension.

UUIDs vs Other ID Formats

UUIDs are not the only option for unique identifiers. Here is how they compare:

Auto-increment integers (1, 2, 3...): Simple, compact (4-8 bytes), and fast. The downside: they are guessable (if you know ID 100 exists, you can try 101), they do not work across distributed databases without coordination, and merging databases requires re-mapping all IDs.

ULID (Universally Unique Lexicographically Sortable Identifier): 128-bit, time-sorted, case-insensitive. Functionally similar to UUID v7 but uses a different encoding (Crockford Base32 instead of hexadecimal). Produces IDs like 01ARZ3NDEKTSV4RRFFQ69G5FAV.

Snowflake IDs (Twitter/X): 64-bit, time-sorted, includes a machine ID and sequence number. Compact and fast. The downside: requires centralized coordination to assign machine IDs, making it unsuitable for truly distributed systems.

NanoID: Shorter random IDs (21 characters by default) using a URL-safe alphabet. Good for URLs and user-facing IDs where a full UUID is too long. Less collision resistance than UUID due to shorter length.

CUID2: Secure, collision-resistant IDs designed for horizontal scaling. Similar goals to UUID v7 but with a different format.

For most web applications, UUID v4 or v7 is the safe, standard choice. The format is universally supported, well-understood, and has first-class support in every major database.

FAQ

Can two UUIDs ever be the same?

Theoretically, yes. Practically, no. A v4 UUID has 2^122 possible values. To have a 50% chance of a collision, you would need to generate about 2.7 x 10^18 (2.7 quintillion) UUIDs. If you generated 1 billion UUIDs per second, it would take about 85 years to reach that point.

Should I use UUIDs or auto-increment integers as primary keys?

UUIDs are better for distributed systems, API-exposed IDs (not guessable), and systems that merge data from multiple sources. Integers are better for simple, single-database applications where you want maximum performance and compact storage. UUID v7 closes much of the performance gap.

How do I store UUIDs in a database?

PostgreSQL has a native uuid type (16 bytes). MySQL can use BINARY(16) for compact storage or CHAR(36) for readability. Always use the native or binary type in production. Storing UUIDs as strings (CHAR 36) wastes space and slows comparisons.

What does the version number in a UUID mean?

The version number (the digit after the second hyphen) tells you how the UUID was generated. v1 uses timestamp + MAC address. v4 is fully random. v5 is a hash of a namespace + name. v7 is timestamp + random. Most applications use v4 or v7.

Can I extract the timestamp from a UUID v7?

Yes. The first 48 bits of a v7 UUID encode the Unix timestamp in milliseconds. Most UUID libraries provide a function to extract it. This means you can determine when a record was created solely from its ID, without needing a separate timestamp column.