Rust UUID v4 Example (uuid crate) + Online Generator

Most pages targeting UUID v4 Rust stop after one code sample. They show the uuid crate, generate a value, and move on. That is enough if you only need syntax. It is not enough if you are choosing an identifier strategy for a real Rust service. Once UUIDs become part of an Axum API, a background worker, a PostgreSQL schema, or an event stream, the useful questions become more specific. How should you configure Cargo.toml? Is UUID v4 a good primary key? What changes if you care about index locality? How does UUID v4 compare with UUID v7 in Rust? And what are the real security implications of exposing random UUIDs in public APIs?

Those questions matter because Rust is often used for systems where performance and operational clarity both matter. The code that generates the UUID is easy. The harder decision is whether a random UUID matches the storage, scaling, and API behavior you actually need.

This page focuses on practical Rust usage rather than generic UUID theory. The goal is to help you decide when UUID v4 is a strong default, when UUID v7 deserves attention, and where a simple sequential key may still be the better internal design.

If you want the primary references alongside the guidance here, the most useful sources are the uuid crate documentation and the modern UUID specification. The sections below translate that material into Rust-specific guidance for production code.

For most Rust projects, the standard answer is the uuid crate. The main setup step is enabling the right features in Cargo.toml. If your code only needs UUID v4 generation and string formatting, keep the dependency narrow and explicit.

[dependencies]
uuid = { version = "1", features = ["v4", "fast-rng", "serde"] }

This is a practical default for many services. The v4 feature enables random UUID generation. serde is useful if UUIDs move through JSON payloads, config, or message formats. fast-rng can improve performance in some workloads, though the right choice depends on your runtime expectations and how often IDs are created.

If you do not need serialization, remove serde. If the project does not need application-side generation, you may not need the v4 feature at all. This matters in Rust because dependency features are part of the build surface. Keep them intentional.

In application code, the usual generation pattern is straightforward:

use uuid::Uuid;

let id = Uuid::new_v4();
println!("{}", id);

That simplicity is useful, but it should not hide the main decision. Adding the crate is the easy part. Choosing where UUID v4 belongs in your system is the harder part.

The main benefit is application-side ID generation. In a Rust web service, the object often needs an identifier before the database write happens. A request handler may want a stable ID for logs, traces, and response payloads. A worker may need an event ID before publishing to a queue. A service may need to create related records that all share the same identifier before persistence is complete. UUID v4 handles that cleanly.

This is especially useful in Rust because many Rust systems are built as explicit, strongly typed boundaries around HTTP, storage, and messaging. A UUID fits naturally in that model. It can be passed through domain types, serialized in API contracts, stored in PostgreSQL, and reused in logs without waiting for a database-generated integer.

There is also a public API reason to use UUID v4. Sequential integer IDs reveal order and rough object counts. A random UUID does not. That does not replace real authorization, but it does make public identifiers less predictable and less informative to outsiders.

In short, Rust teams use UUID v4 when they want one portable identifier created inside the application and reused across several layers of the system.

When Rust developers ask about performance, the first instinct is often to benchmark the generation call itself. That can be useful, but it is rarely the whole story. In most services, the cost of creating a UUID v4 is small compared with database I/O, network latency, JSON serialization, and application logic. The larger performance question is what happens after the value is stored and indexed.

At the code level, there are still a few practical points worth noting. UUID generation depends on randomness, so library features and RNG choices matter. If your code creates large numbers of IDs in a tight path, benchmark the crate configuration you actually ship. Also pay attention to formatting. Converting UUIDs to strings repeatedly can create more overhead than carrying the typed value through the core of the application and formatting only at the boundaries.

In Rust, good performance practice usually means keeping UUIDs as Uuid values in the domain model, serializing when needed, and avoiding unnecessary parse or format churn. The same advice applies to database code. If the driver and schema can work with native UUID values, that is usually better than treating every ID as an arbitrary string.

The important summary is direct: UUID v4 generation is usually not the bottleneck. Database behavior, storage layout, and repeated text conversion are more likely to matter in real workloads.

If you are designing a new Rust service today, the most useful comparison is often not UUID versus integer. It is UUID v4 versus UUID v7. Both give you application-generated identifiers that work cleanly across service boundaries. The difference is how they behave over time.

UUID v4 is random. That makes it simple and opaque, but it also means the values do not sort by creation time. UUID v7 is time-ordered. It keeps the UUID shape and distributed generation model while making the leading bits reflect timestamp order. In practical terms, that gives you IDs that behave more naturally in logs, sorted views, and database indexes.

For many Rust services, the choice comes down to this:

• Choose UUID v4 when randomness and public opacity matter more than insertion order.
• Choose UUID v7 when you still want UUIDs but your write path benefits from time-ordered values.
• Choose a sequential internal key when the database is the only authority creating rows and storage efficiency is the main concern.

That does not make v4 obsolete. It just means it should not be the automatic default for every new Rust service. If the main table is write-heavy, or if ordered identifiers make operations easier, UUID v7 is often the stronger candidate.

The moment UUID v4 becomes a database key, storage behavior matters as much as code ergonomics. PostgreSQL has strong UUID support and is a common fit for Rust applications using SQLx, Diesel, or tokio-postgres. If your schema uses a native UUID column type, the application-level experience is usually clean. The question is not whether PostgreSQL can store UUIDs. It can. The question is whether a random UUID should be the main key for your hottest tables.

Random UUIDs do not insert in order. As a primary key, UUID v4 causes writes to land across the index range instead of appending near the end. In B-tree indexes, that can lead to worse locality than ordered keys. On small tables, the effect may be negligible. On busy tables with heavy write volume, it becomes more noticeable.

This applies beyond PostgreSQL. MySQL and other relational systems face the same basic issue: random keys are harder on indexes than ordered keys. The exact operational cost depends on the engine, schema, row size, and access pattern, but the direction of the trade-off is consistent.

If you use UUID v4 in Rust database code, a few rules help:

• Prefer the database’s native UUID type over plain text storage when it is available.
• Avoid adding unnecessary secondary indexes to random UUID columns.
• Keep the UUID typed in Rust and map it cleanly through the driver instead of converting back and forth to strings everywhere.
• Revisit whether v4 should be the primary key on the busiest tables if inserts are becoming a bottleneck.

Some teams solve this by separating concerns. They keep an internal ordered key for relational efficiency and expose a UUID externally. Others switch the main UUID format from v4 to v7 so they still get application-generated IDs with better write locality. Both approaches are valid. The right choice depends on whether one field is expected to solve both storage and API requirements.

UUID v4 is a good choice for opaque identifiers. It makes resource IDs harder to guess than sequential integers and avoids exposing creation order. That is useful in public APIs, download links, job references, and many service-to-service contracts.

What UUID v4 does not do is replace security controls. A UUID is not an authorization check. It is not a signed token. It is not proof that a client should be allowed to read or modify a resource. Rust developers usually take boundary design seriously, so this is worth stating plainly: an unguessable identifier can reduce casual enumeration, but it does not decide access.

You should also avoid reusing the same UUID format for different trust levels without a clear reason. A public resource ID, an internal correlation ID, and a secret reset token are not the same thing. UUID v4 is fine for the first two. It is often the wrong tool for the third, where expiry, signing, or high-entropy secret material may matter more than UUID compatibility.

From an implementation perspective, keep validation at the boundaries. Parse inbound UUID strings early, reject invalid values cleanly, and avoid letting malformed IDs flow into the core of the application. Rust makes this style natural, and it leads to clearer error handling.

Using string IDs everywhere in application code

Rust gives you a strong typed UUID representation. Use it. Converting everything to String too early creates unnecessary parsing, formatting, and validation work.

Assuming UUID v4 is always the best UUID version

If the table is large and write-heavy, UUID v7 may be the better fit. The fact that v4 is familiar does not make it the best choice for every new service.

Storing UUIDs in inefficient column types

If PostgreSQL or another database supports a native UUID type, use it. Storing UUIDs as generic text by default is easy, but it is often a weaker operational choice.

Treating UUIDs as a security boundary

Opaque IDs help with enumeration risk. They do not replace authorization, authentication, or secret token design.

The uuid crate makes UUID v4 straightforward in Rust, and for many APIs, workers, and distributed services it is still a solid choice. It works well when you need application-generated IDs, public identifiers that do not expose sequence, and values that move cleanly through storage, logs, and message flows.

Be more careful when database indexing, insertion order, and long-term write efficiency matter. That is where UUID v4 stops being a one-line convenience and becomes a system design choice. If your main tables are write-heavy, compare it with UUID v7 before you lock in the format. For modern Rust services, that is usually the comparison that matters most.