Los UUIDs son la primera herramienta a la que recurren la mayoría de los desarrolladores backend cuando necesitan un identificador único que no dependa de una secuencia de base de datos. Están presentes en casi todos los lenguajes, quedan bien en una URL y funcionan sin coordinación entre servicios. Pero el estándar define varias versiones con distintos compromisos, y elegir la adecuada importa en sistemas grandes.

Qué es un UUID

Un UUID (Universally Unique Identifier, también llamado GUID en Windows) es un valor de 128 bits, normalmente escrito como 32 dígitos hex en grupos 8-4-4-4-12. Los cuatro caracteres hex en las posiciones 13–16 codifican la versión (1 a 7); el primer carácter del grupo 17–20 codifica la variante. Lo demás es dato cuyo significado depende de la versión.

Versión 1: tiempo y MAC

v1 codifica el timestamp actual (intervalos de 100 ns desde el 15 de octubre de 1582) más la MAC del host más una secuencia de reloj. Único garantizado sin coordinación — pero filtra cuándo y dónde se generó, lo que suele ser malo. Muchas bases de datos empresariales todavía lo producen por costumbre.

Versión 4: puramente aleatorio

v4 llena 122 de los 128 bits con datos aleatorios de un RNG criptográfico. Los otros 6 bits van fijos para identificarlo como v4. Es el predeterminado en sistemas modernos porque no revela nada, es simple de generar (una línea si crypto.randomUUID está disponible) y tiene una probabilidad de colisión tan pequeña que en la práctica no importa.

Versión 7: ordenada por tiempo

v7 es más nueva (RFC 9562, publicada en 2024). Empieza con un timestamp a milisegundos y rellena el resto con aleatoriedad. El resultado es monótonamente ordenable — útil para claves primarias de base de datos porque v4 fragmenta mucho el índice, mientras v7 mantiene las inserciones agrupadas. Si tu librería lo soporta, prefiere v7 sobre v4 para claves primarias; usa v4 sólo si necesitas ocultar cuándo se creó.

Probabilidad de colisión

Para v4 el espacio es 2^122 — unos 5 × 10^36. Generar mil millones de UUIDs por segundo durante 85 años sigue dando una probabilidad insignificante de colisión. En la práctica, las colisiones en UUID v4 las causan RNGs malos, no el agotamiento del espacio. Usa siempre crypto.randomUUID o crypto.getRandomValues, nunca Math.random.

UUID vs auto-increment

Los IDs auto-increment son más pequeños (8 bytes vs 16), están naturalmente ordenados y son rápidos de indexar — pero filtran datos de negocio ("cuántos pedidos procesa esta empresa al día"), requieren coordinación en sistemas distribuidos y hacen dolorosos los merges entre bases. Los UUIDs son lo contrario: opacos, sin coordinación, grandes. Usa auto-increment en tablas internas donde ningún ID sale de la base. Usa UUIDs para cualquier cosa visible al usuario o intercambiada entre servicios.

Notas de almacenamiento

Guarda los UUIDs siempre como tipo binario nativo si la base lo soporta (UUID en Postgres, BINARY(16) en MySQL). Guardarlos como VARCHAR(36) dobla el espacio y ralentiza cada lookup de índice 2–3x. La forma hex con guiones es sólo para mostrar.