Un UUID v4 es un identificador de 128 bits del que 122 son aleatorios, definido en el RFC 9562 (que sustituye al antiguo RFC 4122). Se usa como clave primaria en bases de datos distribuidas, como identificador de peticiones en trazas y como nombre de fichero irrepetible. Este generador crea UUID en lote con `crypto.getRandomValues()`, la fuente de aleatoriedad criptográfica del navegador: nada viaja a un servidor y puedes generarlos incluso sin conexión.
Qué garantiza realmente la unicidad de un UUID v4
La versión 4 no depende de la MAC ni del reloj: fija 6 bits (4 de versión y 2 de variante) y sortea los 122 restantes. Con 122 bits aleatorios harían falta unos 2,7·10^18 UUID para tener una probabilidad de colisión del 50%; generando mil millones al segundo durante 85 años la probabilidad de un solo choque sigue siendo del orden de 10^-9. La condición es que el generador sea criptográficamente seguro: Math.random() no lo es y no debe usarse jamás para claves, tokens ni identificadores públicos. Aquí se usa la Web Crypto API, la misma que respalda el generador de contraseñas del sitio.
UUID v1, v4 y v7: cuál elegir en 2026
La v1 incrusta timestamp y MAC del host, lo que ordena bien en el índice pero filtra información del servidor. La v4 es puramente aleatoria y es la opción por defecto para identificadores públicos. La v7, estandarizada en el RFC 9562, antepone un timestamp Unix en milisegundos a bits aleatorios: es monótona en el tiempo, así que se comporta como un entero secuencial en un índice B-tree sin exponer la MAC. Regla práctica: v4 cuando el ID viaje al cliente y no necesites orden; v7 cuando vayas a insertar millones de filas y quieras evitar la fragmentación del índice.
UUID como clave primaria: el coste real en PostgreSQL y MySQL
En PostgreSQL el tipo nativo uuid ocupa 16 bytes; guardarlo como varchar(36) cuesta 37 bytes y multiplica el tamaño de todos los índices que lo referencian. En MySQL/InnoDB el problema es distinto: la clave primaria es un índice clusterizado, y una v4 aleatoria provoca inserciones en páginas dispersas, page splits y un aumento medible de la escritura en disco. Las soluciones habituales son usar BINARY(16) con la función UUID_TO_BIN(uuid, 1) para reordenar los bloques del timestamp, o directamente pasarse a UUID v7. Si estás dimensionando el almacenamiento resultante, la calculadora de coste de servidor y el conversor de bytes te ayudan a traducir esos bytes por fila a gigabytes reales.
Formato, mayúsculas y validación
La representación canónica son 32 dígitos hexadecimales en cinco grupos 8-4-4-4-12 separados por guiones, en minúsculas. El RFC obliga a generar en minúsculas pero a aceptar mayúsculas al leer, así que cualquier comparación debe normalizar antes. En un UUID v4 el dígito 13 es siempre 4 y el 17 pertenece al conjunto 8, 9, a o b: por eso una validación estricta con expresión regular detecta identificadores falsificados a mano. Puedes construir y probar ese patrón con el generador de expresiones regulares del sitio.
Usos más allá de la base de datos
Un UUID es el valor ideal para una cabecera X-Request-Id que atraviese balanceador, API y workers: permite reconstruir una petición completa en los logs agregados. También sirve como nombre de objeto en almacenamiento (evita colisiones al subir dos ficheros llamados factura.pdf), como clave de idempotencia en pasarelas de pago y como identificador de instalación en clientes móviles. Lo que un UUID no es: un secreto. Es aleatorio, pero se registra en logs, proxies y cabeceras Referer; para tokens de sesión o de restablecimiento usa el generador de contraseñas o el generador de tokens con más entropía.
Errores frecuentes al trabajar con UUID
Primero, generarlos en el cliente y confiar en ellos sin validar en servidor: un cliente hostil puede enviar el UUID de otro recurso. Segundo, usarlos como token de acceso público asumiendo que "no se adivinan": un enlace con UUID es seguro frente a fuerza bruta, pero no frente a quien lo copie. Tercero, mezclar formatos con y sin guiones en la misma tabla, lo que rompe los JOIN silenciosamente. Cuarto, usar UUID en URLs orientadas a SEO: son ilegibles y no aportan ninguna señal de contenido; para eso conviene un slug legible.
Casos de uso comunes
- Sembrar claves primarias de una tabla nueva sin depender de una secuencia central.
- Generar identificadores de correlación para trazas distribuidas.
- Nombrar objetos en S3 o MinIO evitando colisiones entre subidas simultáneas.
- Crear claves de idempotencia para reintentos de pago o de webhook.
- Rellenar datos de prueba en un entorno de staging.
Buenas prácticas
- Guarda los UUID en el tipo nativo (`uuid` o `BINARY(16)`), nunca como texto de 36 caracteres.
- Normaliza siempre a minúsculas antes de comparar o indexar.
- Usa UUID v7 si vas a insertar volúmenes altos y te preocupa la fragmentación del índice.
- No trates un UUID como secreto: para tokens usa entropía dedicada y caducidad.