UUID
Generator

UUID v4 is the workhorse. 122 random bits plus 6 fixed version/variant bits, generated from a cryptographically secure RNG. Collision probability is so low (you would need to generate ~1 billion UUIDs per second for ~85 years to have a 50 % chance of a collision) that it can be treated as zero at internet scale. Use it as the default for almost everything.

UUID v1 encodes a 60-bit timestamp plus a MAC address and a clock sequence. It is sortable by creation time but leaks the host's MAC and the exact creation moment, which is a privacy concern. Most modern systems avoid v1 because of that leak and because the timestamp ordering is awkward (low bits come first).

UUID v7 (RFC 9562, 2024) is the modern alternative to v1: a 48-bit Unix-millisecond timestamp in the high bits, followed by random bits. It is lexicographically sortable, which makes it dramatically better for B-tree primary keys than v4 (which fragments the index because inserts are scattered). Use v7 for new database designs where you want UUIDs and good index locality.

NIL UUID (00000000-0000-0000-0000-000000000000) is a sentinel meaning 'no value' — useful as a default in optional FK columns or as a placeholder in tests. The Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) is the equivalent ceiling sentinel for range queries.

ToolSeo.uuid-generator.section1.p5

Auto-increment integers (BIGSERIAL in Postgres, AUTO_INCREMENT in MySQL) are tiny (8 bytes), cache-friendly, and produce dense B-tree indexes. Their downside is that they leak business information — anyone seeing order=4217 can guess your order volume — and they make multi-master writes painful because the database server must coordinate the next value.

UUIDs are 16 bytes (2× the storage and index cost of a BIGINT), do not leak counts, can be generated client-side without a round-trip, and survive offline-first workflows where IDs need to exist before the row reaches the server. They are also URL-safe and globally unique across shards, services, and databases.

The pragmatic stack: UUID v7 for the primary key (good index locality, no count leak, client-generatable), an optional human-friendly BIGINT order_number column for display in the UI, and an optional opaque public_id (Nano ID or short hash) for URLs that need to look pretty.

Do not use UUID v4 as a primary key on a large hot table without thinking it through — its randomness causes severe write-amplification on B-tree indexes. Either use UUID v7, or use BIGINT primary keys with a separate UUID column for external references.

ToolSeo.uuid-generator.section2.p5

A UUID is fundamentally 16 bytes. Stored as a binary(16) or Postgres uuid type, it costs 16 bytes per row. Stored as the canonical hyphenated string (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), it costs 36 bytes plus per-row overhead — more than 2× the binary cost.

On Postgres, always use the native uuid type — it stores binary internally, accepts string input/output transparently, and supports indexing and ordering correctly. MySQL has no native UUID type; use BINARY(16) with helper functions UUID_TO_BIN and BIN_TO_UUID, optionally with the rearrangement flag for index-friendly storage.

For APIs, return the hyphenated string form. It is the universal exchange format. Base64 or Base58 encodings produce shorter strings (22 and 22 chars respectively vs 36) but break tooling — debuggers, log greps, and SQL clients all expect the hyphenated form. Save the encoded short forms for URL slugs only.

ToolSeo.uuid-generator.section3.p4

ToolSeo.uuid-generator.section3.p5

ToolSeo.uuid-generator.section4.p1

ToolSeo.uuid-generator.section4.p2

ToolSeo.uuid-generator.section4.p3

ToolSeo.uuid-generator.section4.p4

ToolSeo.uuid-generator.section4.p5

ToolSeo.uuid-generator.section5.p1

ToolSeo.uuid-generator.section5.p2

ToolSeo.uuid-generator.section5.p3

ToolSeo.uuid-generator.section5.p4

ToolSeo.uuid-generator.section5.p5