Cose un UUID e a cosa serve: identificatori unici universali
Scopri cose un UUID, versioni v1 v4 v7, quando usarli e come generarli.
What is a UUID and why it exists
A UUID (Universally Unique Identifier) is a 128-bit identifier (32 hex characters) designed to be unique without a central server. Example: 550e8400-e29b-41d4-a716-446655440000.
Why it matters: In distributed systems (microservices, replicated databases, offline-first apps), you can't rely on centralized auto-increment. UUIDs let any node generate IDs without coordination.
Collision probability: For UUID v4, you'd need 2.7 quintillion (2.7x10^18) to have 50% collision chance. Generating 1 billion/second would take 86 years.
Generate UUIDs instantly with the NexTools UUID generator.
UUID versions: v1, v4, v7 and when to use each
| Version | Based on | Sortable | Predictable | Recommended use |
|---|---|---|---|---|
| v1 | Timestamp + MAC | Yes (partial) | Yes (leaks MAC) | Legacy, avoid in new projects |
| v4 | Random | No | No | Most used. Default for most cases |
| v5 | SHA-1 hash of namespace+name | No | Deterministic | Consistent UUID for given input |
| v7 | Unix ms timestamp + random | Yes (chronological) | Partially | Databases (better index performance) |
2026 recommendation: v4 by default. v7 for database primary keys needing chronological order. v5 for deterministic IDs.
The NexTools generator creates random v4 UUIDs.
UUID vs auto-increment vs ULID vs nanoid
| Type | Length | Sortable | Collision-safe | Readable |
|---|---|---|---|---|
| Auto-increment | Variable | Yes | Yes (centralized) | Yes |
| UUID v4 | 36 chars | No | Yes (decentralized) | No |
| UUID v7 | 36 chars | Yes | Yes | No |
| ULID | 26 chars | Yes | Yes | Better |
| nanoid | 21 chars | No | Yes | Best (URL-safe) |
When to use each: Auto-increment for simple single-server DBs. UUID v4 for public APIs and distributed systems. UUID v7/ULID for high-volume DB primary keys. nanoid for short URLs and session tokens.
UUIDs in databases: performance and best practices
The v4 primary key problem: Random UUIDs cause B-tree index fragmentation. Each INSERT goes to a random position. On millions of rows, inserts are 2-5x slower than auto-increment.
Solution 1: UUID v7. Starts with timestamp, so chronologically ordered. Inserts always go to index end.
Solution 2: ULID. Like v7 but more compact (26 chars) with better encoding.
PostgreSQL: Use native uuid type (16 bytes). PostgreSQL 17+ has native v7 support.
MySQL: Store as BINARY(16), not VARCHAR(36). Huge performance difference.
Security: are UUIDs safe as tokens
UUID v4 is NOT a security token. It has 122 random bits (enough to be unique) but wasn't designed to be cryptographically unpredictable.
For auth tokens: Use crypto.randomBytes(32) (Node.js) or secrets.token_hex(32) (Python). These use CSPRNG.
UUIDs in URLs: Exposing UUIDs as resource IDs (/api/users/550e8400-...) is generally fine. But NOT for access tokens, password reset links, or anything granting privileges.
For secure passwords, use the NexTools password generator. For data hashing, the hash generator.
How to generate UUIDs: tools and code
Online: The NexTools UUID generator creates v4 in your browser. All local.
JavaScript/Node.js: import { randomUUID } from 'crypto'; console.log(randomUUID());
Python: import uuid; print(uuid.uuid4())
Terminal: uuidgen
PostgreSQL: SELECT gen_random_uuid();
MySQL: SELECT UUID(); (generates v1, not v4)
Anatomy of a UUID: what each part means
UUID v4 format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
Example: 550e8400-e29b-41d4-a716-446655440000
- Position 13 (the "4"): Version (4=random, 7=timestamp)
- Position 17 (the "a"): Variant (8,9,a,b = RFC 4122)
- Rest: 122 random bits (v4) or timestamp + random (v7)
Dashes are optional. 550e8400e29b41d4a716446655440000 is the same UUID.
Size: 128 bits = 16 bytes. String with dashes: 36 chars. Hex without: 32. Base64: 22.
UUIDs in the real world: who uses them
Databases: PostgreSQL uses UUIDs extensively. MongoDB uses ObjectIDs (12 bytes, similar concept). DynamoDB recommends UUIDs as partition keys.
APIs: Most REST APIs use UUIDs for resource IDs. Stripe, Twilio, GitHub, AWS all return UUIDs.
Bluetooth: Uses UUIDs to identify services and characteristics.
Microsoft COM: GUIDs (Globally Unique Identifiers) are UUIDs. Every COM component has a unique GUID.
File systems: GPT (GUID Partition Table) uses UUIDs for disk partitions.
Prova questo strumento:
Apri strumento→Domande frequenti
Can a UUID repeat or collide
Theoretically yes, but probability is astronomically low. For v4, you'd need 2.7 quintillion for 50% collision chance. In practice, a UUID v4 collision is less likely than being hit by a meteorite.
Which UUID version should I use
v4 (random) for most cases. v7 for chronological DB ordering. v5 for deterministic IDs. Avoid v1 in new projects (exposes MAC address).
Can I use UUID as a password or security token
Not recommended. v4 has good randomness but wasn't designed as a crypto token. For auth tokens use crypto.randomBytes() or equivalent CSPRNG.
Why is UUID v4 slow as a database primary key
Random values cause B-tree index fragmentation. Every INSERT goes to a random position. UUID v7 or ULID fix this by being chronologically ordered.
Are UUID and GUID the same thing
Practically yes. GUID is Microsoft's term for UUID. Format and generation are identical. UUID is the standard term (RFC 4122).
Can I shorten a UUID to make it more readable
Yes. Encode in Base64 (22 chars) or Base62 (22 chars, URL-safe). Or use alternatives like nanoid (21 chars) or ULID (26 chars). Trade-off: less compatibility with UUID-expecting tools.