The UX of UUIDs

Original Article ↗ Hacker News Discussion ↗

Uniqueness and collision risk

  • Several comments stress that UUIDs are only “unique” once a system prevents reuse (e.g., via a DB uniqueness constraint).
  • Others reply that properly generated 128‑bit random UUIDs have astronomically low collision probability; practical risks come more from bugs or hardware faults than true collisions.
  • The birthday paradox is invoked to correct an overoptimistic collision estimate in an extreme thought experiment.

Client-side generation and security

  • UUIDs are praised for distributed, coordination‑free ID generation.
  • However, if clients can choose IDs, malicious users can deliberately collide with existing IDs to access others’ data.
  • Suggested mitigations: server‑side uniqueness checks, or server‑generated IDs, unless offline/latency-hiding use cases require client-side generation.

UUIDs as database primary keys

  • Critics note performance issues with random UUIDs as clustered primary keys (e.g., page splits, WAL growth).
  • Alternatives: monotonic integers (bigserial), k‑sortable IDs, or UUIDv7.
  • Others argue UUID PKs greatly simplify distributed/offline data merging, even if performance is worse in a single central DB.

Alternative ID formats (ULID, TypeID, etc.)

  • Multiple alternatives are mentioned: TypeID, ULID, KSUID, CUID, shortUUID, snowflake‑style IDs, base24/base32 schemes, etc.
  • Debates:
    • Some say ULID should be deprecated in favor of UUIDv7; others claim ULID still has advantages (more precise timestamp, friendlier string form).
    • TypeID is seen as a nice wrapper over UUIDv7 with type prefixes; critics worry type‑coupled IDs can become brittle as concepts change.

Human UX: copying, reading, speaking

  • Hyphens break “double‑click to select” behavior; proposals include removing hyphens or using underscores or other separators.
  • Counters argue separators aid manual transcription and chunking; removing them hurts rare but important manual tasks.
  • CSS user-select: all and explicit copy buttons are recommended where possible, but don’t help in terminals, DB clients, or address bars.
  • Some note that most users copy‑paste rather than type IDs, so readability tweaks may have limited benefit.

Encodings, alphabets, and swear words

  • Base58 is favored for omitting ambiguous characters (I, l, O), but criticized as slower and case‑sensitive.
  • Hex/base16 and Crockford’s base32 are popular for simplicity and case‑insensitivity.
  • Marketing concerns about accidental swear words arise; suggested mitigations include restricted alphabets or rerolling offending IDs.