- What is the difference between UUID v4 and UUID v7?
- UUID v4 is fully random (122 bits of randomness). UUID v7 (RFC 9562) embeds a Unix millisecond timestamp in the first 48 bits, making IDs sortable by creation time. Use v7 for database primary keys; use v4 for general-purpose random identifiers.
- Is GUID the same as UUID?
- Yes. GUID (Globally Unique Identifier) is the Microsoft/.NET term for the same 128-bit identifier format. GUIDs and UUIDs are interchangeable and use the same 8-4-4-4-12 hexadecimal representation.
- Can UUIDs collide?
- Theoretically yes, but the probability is astronomically low. For UUID v4, you would need to generate 2.71 × 10^18 UUIDs to have a 50% chance of a single collision — far more than any production system will ever create.
- Which UUID version is best for database primary keys?
- UUID v7 is recommended for new projects. Its time-ordered prefix causes sequential inserts in B-tree indexes, reducing page splits and improving write performance in PostgreSQL and MySQL. UUID v4 causes random inserts that fragment indexes.
- What are UUID v3 and v5 used for?
- v3 (MD5) and v5 (SHA-1) generate deterministic UUIDs from a namespace and name. The same inputs always produce the same UUID. Useful for generating stable IDs from known data like URLs or email addresses.
- Can I generate UUIDs in bulk?
- Yes. Bulk mode supports up to 1000 UUIDs at once. Useful for database seeding, test fixtures, CSV imports, batch API operations, or migrating to UUID-based primary keys. Copy as newline-separated or download as .txt / .csv.
- Are UUIDs cryptographically secure?
- UUID v4 uses cryptographically secure randomness from the browser's CSPRNG (window.crypto.getRandomValues()) so they're unguessable. UUID v1 reveals creation timestamp and node ID, so it's NOT suitable as a security token. For security tokens, prefer UUID v4 or longer random tokens (32+ hex chars from our Token Generator).
- Can I use UUID as a primary key in PostgreSQL?
- Yes — PostgreSQL has a native `uuid` column type. For new tables, prefer UUID v7 over v4 to avoid B-tree index fragmentation. Schema: `CREATE TABLE users (id uuid PRIMARY KEY DEFAULT gen_random_uuid(), ...)`. For v7, use a v7 implementation library or generate client-side and INSERT. The 16-byte storage is half of varchar(36) storage.
- What is UUID v8?
- UUID v8 (RFC 9562, published 2024) is the 'custom variant' — application-specific schemes that embed your own structured data. v8 is rarely needed; only use it if you need to encode something specific (e.g., tenant ID + entity type + timestamp) into the UUID itself. For 99% of use cases, v4 (random) or v7 (sortable) is what you want.
- Should I trim dashes from UUIDs for URLs?
- Optional — both formats encode the same 128 bits. Dashes make UUIDs human-readable but add 4 wasted bytes per URL. For high-volume APIs (millions of URLs), dashless saves bandwidth. For human-shared URLs (admin panels, support links), keep dashes for readability. Even shorter: Base64URL-encode the UUID to 22 chars.
- Do UUIDs work in MySQL and MongoDB?
- Yes. MongoDB's native ObjectId is similar in concept (12-byte timestamp-prefixed ID) but you can also store UUIDs as `BinData(4, ...)` or strings. MySQL has no native UUID type — use `BINARY(16)` for compact storage or `CHAR(36)` for human-readable. For sortable inserts, store v7 UUIDs as `BINARY(16)` since MySQL preserves byte order for B-tree indexing.
