UUID Explained: UUID v4 vs UUID v7, Generators, Database IDs, and Best Practices

If you’ve ever needed to create a unique ID for a database record, API resource, user, transaction, file, or background job, you’ve probably encountered a UUID.

You may have seen something like:

550e8400-e29b-41d4-a716-446655440000

It looks complicated, but the basic idea is simple.

A UUID is a 128-bit identifier designed to make accidental duplication extremely unlikely. UUIDs are also commonly called GUIDs, or Globally Unique Identifiers. The current IETF UUID specification is RFC 9562, published in May 2024.

The interesting part is that not every UUID works the same way.

• UUID v4 is random or pseudorandom.
• UUID v7 combines a timestamp with randomness and produces values that are time-ordered.

That difference becomes particularly important when UUIDs are used as database primary keys. You can experiment with our free UUID generator or validate an existing ID with the UUID checker as you read.

What Is a UUID?

UUID stands for Universally Unique Identifier.

It is a 128-bit value used to identify something without requiring a central authority to assign every ID.

A standard textual UUID looks like this:

550e8400-e29b-41d4-a716-446655440000

The standard representation contains:

• 32 hexadecimal characters
• 4 hyphens
• 36 characters in total

The 32 hexadecimal characters represent 128 bits because each hexadecimal character represents 4 bits.

So:

32 × 4 = 128 bits

The hyphens are formatting characters. They don’t add any information.

RFC 9562 defines UUIDs as 128-bit values and specifies multiple UUID versions with different generation methods.

UUID vs GUID: Are They Different?

In most modern development contexts, UUID and GUID refer to essentially the same type of identifier.

UUID means:

Universally Unique Identifier

GUID means:

Globally Unique Identifier

You may encounter the term GUID particularly in Microsoft ecosystems.

For example, developers may talk about:

• GUID code
• GUID generator
• online GUID generator
• GUID v4
• unique GUID

The underlying concept is still a 128-bit identifier.

The exact representation and behavior can depend on the implementation, so the terms shouldn’t be treated as a guarantee that every system handles the bytes identically.

What Does a UUID Generator Actually Do?

A UUID generator creates a new identifier according to the rules of a particular UUID version.

That last part is important.

A UUID generator isn’t simply producing 32 random hexadecimal characters.

A valid UUID has structural requirements.

For example, UUID v4 reserves bits for the version and variant while using the remaining bits for random data. RFC 9562 specifies 122 bits of random data for UUID v4 when generated according to its random-data layout.

A UUID v7 works differently.

It places a Unix timestamp in the most significant 48 bits and uses the remaining space for randomness and, optionally, mechanisms that provide additional monotonicity.

So when you click Generate UUID, the important question isn’t simply “Did it create a random string?”

The important question is:

Which UUID version did it generate, and did it follow the standard?

How to Generate a UUID Online

For a simple identifier, you can use an online UUID generator.

Typical options include:

• Generate UUID
• Generate random UUID
• Generate UUID v4
• Generate UUID v7
• Generate UUIDs in batches
• Generate GUID
• Generate unique IDs

If you need a UUID for testing, development, documentation, or a temporary identifier, an online UUID generator can be convenient.

For production applications, however, you should normally generate IDs programmatically inside your application or database rather than manually copying them from a website.

The generator should also use an appropriate source of randomness.

What Is UUID v4?

UUID v4 is the familiar random UUID.

RFC 9562 defines UUID v4 as a UUID generated from truly random or pseudorandom data, with the required version and variant bits applied.

A typical UUID v4 looks like:

f47ac10b-58cc-4372-a567-0e02b2c3d479

Notice the 4 in the third group:

4372

That identifies it as version 4.

The important characteristic is that UUID v4 does not encode a creation timestamp in the way UUID v7 does.

It is fundamentally a random identifier.

What Is UUID v7?

UUID v7 is a newer UUID format defined by RFC 9562.

Instead of making the entire useful portion random, UUID v7 places a Unix timestamp in milliseconds at the beginning of the UUID.

The remaining bits provide randomness and can optionally support additional monotonicity mechanisms.

A UUID v7 might look like:

019535d9-3df7-79fb-b466-fa907fa17f9e

The 7 in the third group identifies the UUID version.

The beginning of the UUID contains time-ordering information.

That gives UUID v7 a property UUID v4 doesn’t naturally provide:

newly generated UUIDs can be roughly ordered by creation time.

UUID v4 vs UUID v7: What’s the Difference?

This is the most important comparison in modern UUID discussions.

Feature	UUID v4	UUID v7
Main design	Random	Time-ordered
Timestamp included	No	Yes
Randomness	Very high	High
Sortable by creation time	No	Yes, broadly
Database locality	Generally worse for ordered indexes	Generally better suited
Predictable creation time	No	Timestamp is encoded
Useful for	General random IDs	Databases, distributed systems, ordered IDs

RFC 9562 specifically describes UUID v7 as time-ordered and says implementations should use UUID v7 instead of UUID v1 and UUID v6 when possible.

That doesn’t mean UUID v7 replaces UUID v4 everywhere.

They solve slightly different problems.

Should You Use UUID v4 or v7 for Your Database?

This is one of the most useful architectural questions to ask.

If you need a simple randomly generated identifier and don’t care about ordering, UUID v4 can be perfectly appropriate.

If you’re generating very large numbers of database records and want identifiers with time-ordering characteristics, UUID v7 is particularly interesting.

The reason is database index behavior.

Randomly distributed identifiers can create less predictable insertion patterns in indexes.

Time-ordered identifiers can provide better locality for workloads where records are continuously inserted.

That doesn’t mean UUID v7 will automatically make every database faster.

Database performance depends on:

• Database engine
• Index design
• Workload
• Table size
• Query patterns
• Storage engine
• Hardware
• Write volume
• Number of indexes

So UUID v7 should be considered a database-design option, not a universal performance switch.

Why Do Developers Say UUID Is Bad for Primary Keys?

The criticism usually isn’t that UUIDs are inherently bad.

It’s about trade-offs.

A UUID is 128 bits.

A typical 64-bit integer is half that size.

A random UUID also doesn’t naturally provide the sequential insertion behavior of an auto-incrementing integer.

That can matter for database indexes and storage.

UUIDs can also be less convenient to read manually.

Compare:

10482

with:

019535d9-3df7-79fb-b466-fa907fa17f9e

The integer is much easier for a human to read.

But UUIDs provide a major advantage in distributed systems:

different systems can generate IDs independently without coordinating a central sequence.

PostgreSQL’s documentation explicitly notes that UUIDs can provide a better uniqueness guarantee across distributed systems than sequence generators, which are unique within a database.

UUID vs Auto-Increment: Which Should You Use?

There isn’t one correct answer.

Auto-increment integers

Advantages:

• Small
• Simple
• Easy to read
• Efficient for many database indexes
• Naturally ordered

Disadvantages:

• Centralized sequencing
• IDs can reveal approximate record counts
• More difficult to generate independently across multiple systems

UUIDs

Advantages:

• Large identifier space
• Can be generated independently
• Useful across distributed systems
• Harder to guess sequentially
• Suitable for APIs and distributed architectures

Disadvantages:

• Larger than integers
• More storage
• Less human-readable
• Random UUIDs can have database locality disadvantages

UUID v7

UUID v7 adds another useful property:

time ordering.

That’s why it can be an attractive compromise for systems that want distributed UUID generation without completely abandoning ordering characteristics.

Can You Use UUID as a Database Primary Key?

Yes.

PostgreSQL has a native uuid data type. Its documentation describes UUID as a 128-bit quantity and supports storing UUIDs regardless of where or how they were generated.

For example:

CREATE TABLE users (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL
);

You can then insert a generated UUID.

The important question isn’t whether PostgreSQL allows UUID primary keys.

It does.

The architectural question is whether UUID is appropriate for your workload.

How to Generate UUID v4 in PostgreSQL

Modern PostgreSQL provides built-in UUID generation functions.

For UUID v4:

SELECT gen_random_uuid();

PostgreSQL also provides:

SELECT uuidv4();

in current documentation.

Both generate UUID v4 values.

You can use one as a default:

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name TEXT NOT NULL
);

Now PostgreSQL can generate the identifier automatically when you insert a record without specifying id.

How to Generate UUID v7 in PostgreSQL

Current PostgreSQL documentation also provides:

SELECT uuidv7();

This generates a version 7 UUID.

You can use it as a default:

CREATE TABLE events (
    id UUID PRIMARY KEY DEFAULT uuidv7(),
    event_type TEXT NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

This can be useful for event-oriented tables where IDs benefit from time ordering.

Is a UUID Always 36 Characters Long?

No.

This is a common misunderstanding.

The canonical textual representation contains 36 characters:

32 hexadecimal characters + 4 hyphens = 36 characters

But the UUID itself is only:

128 bits = 16 bytes

The hyphens are presentation formatting.

A UUID can therefore be represented without hyphens:

550e8400e29b41d4a716446655440000

That’s 32 hexadecimal characters.

PostgreSQL, for example, accepts UUID input without hyphens, although its standard output uses the conventional hyphenated form.

How to Generate a 32-Character UUID Instead of 36

If you need a 32-character representation, you usually aren’t creating a different UUID.

You’re removing the four hyphens from the standard textual representation.

For example:

36-character form:

550e8400-e29b-41d4-a716-446655440000

32-character form:

550e8400e29b41d4a716446655440000

Both represent the same 128-bit UUID.

The distinction is therefore:

UUID value ≠ textual formatting

If an API requires exactly 32 hexadecimal characters, removing the hyphens can satisfy the formatting requirement.

But don’t confuse that with generating a “32-character UUID standard.”

How Many Characters Does a UUID Actually Have?

There are several ways to describe it:

Binary UUID:

128 bits / 16 bytes

Hexadecimal UUID without hyphens:

32 characters

Canonical textual UUID:

36 characters

The standard canonical representation groups the hexadecimal characters as:

8-4-4-4-12

For example:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

That’s:

8 + 4 + 4 + 4 + 12 = 32 hexadecimal characters

plus four hyphens = 36 characters.

What Is a UUID Example?

Here’s a UUID v4 example:

550e8400-e29b-41d4-a716-446655440000

The third group begins with 4, indicating version 4.

Here’s a UUID v7 example:

019535d9-3df7-79fb-b466-fa907fa17f9e

The third group begins with 7, indicating version 7.

The exact values aren’t important.

The structure and version are.

How Do You Know Which UUID Version You Have?

Look at the first hexadecimal character of the third group.

For example:

550e8400-e29b-41d4-a716-446655440000

The groups are:

550e8400

e29b

41d4

a716

446655440000

The third group starts with:

4

Therefore, it is UUID v4.

For UUID v7:

019535d9-3df7-79fb-b466-fa907fa17f9e

The third group is:

79fb

The first character is:

7

Therefore, it is UUID v7.

What Is a UUID Identifier Used For?

UUIDs can identify many different things:

• Users
• Products
• Orders
• Transactions
• Files
• API resources
• Sessions
• Events
• Jobs
• Devices
• Database records

They’re particularly useful when multiple systems need to create identifiers independently.

Imagine three application servers creating records simultaneously.

With a centrally managed integer sequence, the database can coordinate the numbers.

With UUIDs, each application can generate identifiers independently.

That can simplify distributed architectures.

Is UUID Overkill for a Small Project?

Sometimes.

If you’re building a tiny application with one database and a few tables, an integer primary key may be simpler.

You don’t need UUIDs merely because modern applications use them.

On the other hand, UUIDs can make sense from the beginning if:

• You expect distributed services
• IDs are exposed through APIs
• Multiple systems create records
• You want IDs that aren’t simple sequential numbers
• You plan to synchronize data between systems

The correct question isn’t:

“Are UUIDs modern?”

It’s:

“What properties does my identifier need?”

Can Hackers Use My UUID Against Me?

A UUID isn’t automatically a secret.

You should generally assume that a UUID used as an API resource identifier can become visible.

A UUID does not automatically provide authorization.

For example, this is dangerous:

GET /users/019535d9-3df7-79fb-b466-fa907fa17f9e

If your server returns the user’s private data to anyone who knows the UUID, the problem isn’t that the UUID was visible.

The problem is missing authorization.

UUIDs can make sequential guessing harder than simple integer IDs, but they should never replace authentication and authorization controls.

UUID v7 deserves additional consideration because its timestamp component can reveal timing information about when the UUID was generated. RFC 9562 explicitly defines the timestamp component of v7.

UUID Security: What Information Does It Reveal?

The answer depends on the UUID version.

UUID v4 primarily contains random data plus the required version and variant bits.

UUID v7 contains a Unix timestamp in its most significant 48 bits.

That means UUID v7 is not equivalent to a completely opaque random token.

If you expose a UUID v7 publicly, someone who understands the format can derive timing information from it.

That isn’t necessarily a security problem.

But it’s an architectural characteristic you should know about.

And neither UUID v4 nor UUID v7 should be treated as a password, API secret, authentication token, or authorization mechanism.

How Do You Prevent UUID Collisions?

The main answer is to use a standards-compliant generator with an appropriate source of randomness.

For UUID v4, RFC 9562 defines 122 random bits after accounting for the version and variant fields.

The possible space is enormous.

A properly generated UUID v4 collision is extraordinarily unlikely.

But “extremely unlikely” isn’t the same as “mathematically impossible.”

Your application should still enforce uniqueness where uniqueness is required.

For example:

CREATE TABLE users (
    id UUID PRIMARY KEY
);

The primary-key constraint gives the database the final authority over uniqueness.

What Happens When a UUID Generator Fails?

This is where production systems differ from simple UUID generator websites.

If your application can’t generate an identifier, you need an explicit failure strategy.

Depending on your architecture, you might:

• Retry
• Fail the transaction
• Generate the ID in the database
• Use a different trusted generator
• Queue the operation
• Alert the system
• Preserve idempotency information

Don’t silently create an empty or predictable fallback ID.

For example, replacing a failed UUID with:

00000000-0000-0000-0000-000000000000

is not a legitimate uniqueness strategy.

UUID Batch Generator: When Do You Need One?

A UUID batch generator creates multiple UUIDs at once.

For example, you might need 1,000 IDs for:

• Database testing
• Seed data
• Mock API responses
• Automated tests
• Import files
• Development environments

For testing, generating UUIDs in batches can save time.

For production systems, however, IDs should generally be generated as part of the application or data-processing workflow rather than manually generated and pasted into production.

UUID Performance: Does It Matter?

Yes, but context matters.

UUIDs consume more storage than smaller integer identifiers.

They can also increase index size.

Random UUID v4 values can have poorer insertion locality than sequential identifiers.

UUID v7 addresses an important part of this problem by introducing time ordering.

But performance should be measured against your actual workload.

If your application has 5,000 records, obsessing over UUID index behavior may accomplish very little.

If you’re operating a high-write system with huge tables and several indexes, identifier design can become much more important.

UUID vs Natural Keys

A natural key is an identifier derived from real-world data.

Examples include:

• Email address
• National identifier
• Product code
• Username

Natural keys can look attractive because they have meaning.

But real-world values change.

Emails change.

Product codes change.

Business rules change.

UUIDs have no business meaning, which can be an advantage.

You can therefore separate:

Internal identity

from:

Business information

A product’s UUID doesn’t need to change simply because its display name changes.

UUIDs for APIs

UUIDs are commonly useful for API resource identifiers.

Instead of:

/api/users/12345

you might expose:

/api/users/019535d9-3df7-79fb-b466-fa907fa17f9e

This doesn’t make an API secure by itself.

Authorization is still required.

But UUIDs can avoid exposing simple sequential identifiers and make distributed ID generation easier.

For APIs where identifiers are generated independently across multiple services, UUIDs can be particularly convenient.

UUID Generation in Different Programming Languages

Most mainstream languages have UUID libraries or standard-library support.

Typical approaches include:

JavaScript / Node.js

import { randomUUID } from "node:crypto";

const id = randomUUID();

Python

import uuid

id = uuid.uuid4()

Java

Java provides UUID functionality through its standard libraries.

Go

Go applications commonly use established UUID packages.

PostgreSQL

SELECT gen_random_uuid();

or current PostgreSQL:

SELECT uuidv4();

For UUID v7, use a library or database implementation that explicitly supports RFC 9562 UUID v7.

The important part is not the programming language.

It is choosing an implementation that actually generates the UUID version you intend to use.

Best Practices for Generating Unique IDs

A reliable ID strategy should answer several questions before you write the first line of code.

1. What must the ID be unique across?

One database?

Multiple databases?

Multiple services?

Multiple regions?

The scope matters.

2. Does the ID need ordering?

If yes, UUID v7 deserves consideration.

3. Will users see it?

If yes, consider whether exposing the identifier creates information leakage or enumeration concerns.

4. Is the ID a secret?

If yes, don’t use a UUID as a substitute for a cryptographic secret.

5. Does the database need efficient indexing?

If yes, compare UUID v4, UUID v7, integer IDs, and your actual workload.

6. Does the application need offline generation?

UUIDs can be useful because individual systems can generate IDs without waiting for a central sequence.

UUID Batch Processing and Large Systems

UUID design becomes particularly interesting in distributed and batch systems.

Suppose a system processes millions of records from several workers.

You don’t necessarily want every worker asking one central service:

“Give me the next ID.”

That introduces coordination.

Instead, workers can generate identifiers independently.

UUIDs are useful for this model because uniqueness is built into the identifier-generation approach.

For extremely large systems, however, ID generation is only one part of scalability.

You still need to think about:

• Database indexes
• Batch sizes
• Transactions
• Retry behavior
• Idempotency
• Queue design
• Partitioning
• Query performance

A UUID won’t fix a badly designed batch-processing system.

UUID v4 or UUID v7 for a New Project?

The choice can be simplified.

Choose UUID v4 when you primarily need a random, decentralized identifier and don’t need time ordering.

Consider UUID v7 when you want UUIDs that carry creation-time information and have time-ordered characteristics.

For new database-heavy systems, UUID v7 is worth evaluating rather than automatically defaulting to UUID v4.

The current RFC explicitly recommends UUID v7 over UUID v1 and UUID v6 when possible.

But that doesn’t mean every existing UUID v4 application should migrate.

Migration has a cost.

If UUID v4 already works correctly and database performance is acceptable, changing identifier formats may provide little practical benefit.

Should You Migrate From UUID v4 to UUID v7?

Not automatically.

Migration can affect:

• Database schema
• Primary keys
• Foreign keys
• Indexes
• APIs
• URLs
• External integrations
• Cached data
• Logs
• Analytics
• Application code

Changing a primary-key format simply because a newer UUID version exists can create enormous unnecessary complexity.

Evaluate the actual problem first.

If random UUID insertion is causing measurable database performance issues, UUID v7 may be worth investigating.

If there is no problem, migration may not be justified.

What Is the Future of UUIDs?

The UUID ecosystem has moved beyond the older assumption that every UUID should simply be random or timestamp-based in the same way.

RFC 9562 formally defines UUID versions 6, 7, and 8 alongside earlier versions.

UUID v7 is particularly relevant because it combines:

time ordering + large random space

That makes it attractive for modern distributed applications and database-heavy workloads.

PostgreSQL now provides native UUID v7 generation, which makes adoption easier for PostgreSQL applications.

UUID Quick Reference

Question	Answer
What is UUID?	A 128-bit identifier
What is GUID?	Common alternative term for UUID
UUID v4	Random/pseudorandom UUID
UUID v7	Time-ordered UUID with timestamp + randomness
Standard UUID text length	36 characters
Hex characters	32
UUID binary size	16 bytes
UUID v4 timestamp?	No embedded creation timestamp
UUID v7 timestamp?	Yes
Can UUID be a primary key?	Yes
Can UUID be used in APIs?	Yes
Is UUID a password?	No
Is UUID automatically secure?	No
Can UUIDs collide?	Extremely unlikely with proper generation, but uniqueness constraints should still be enforced
PostgreSQL v4	gen_random_uuid() / uuidv4()
PostgreSQL v7	uuidv7()

PostgreSQL’s current documentation supports UUID v4 and UUID v7 generation directly.

The Bottom Line

A UUID is not simply a long random string.

It’s a standardized 128-bit identifier with multiple versions designed for different purposes.

UUID v4 is primarily random.

UUID v7 combines a Unix timestamp with randomness and provides time-ordered characteristics.

If you just need a random unique identifier, UUID v4 remains useful.

If you’re designing a new database-heavy system and want distributed IDs with ordering characteristics, UUID v7 deserves serious consideration.

And if you’re wondering whether UUID is better than an auto-incrementing integer, the answer depends on your architecture.

Use integers when compact, simple, sequential database identifiers are exactly what you need.

Use UUIDs when decentralized generation, distributed systems, API identifiers, or globally unique identifiers provide real value.

Most importantly, don’t confuse a UUID with a security mechanism.

A UUID identifies something.

Authentication, authorization, encryption, and secrets management are what protect it.

For a developer building a new system today, the practical starting point is simple:

Understand the identifier’s requirements first, then choose between UUID v4, UUID v7, numeric IDs, or another strategy based on the actual workload.

Generate UUIDs online for free — our UUID generator produces v1, v4, and v5 UUIDs in any quantity, entirely in your browser. Check an existing ID with the UUID checker to confirm its version.