Generar UUID

Si es la clave primaria de una base de datos, v7. Si debe ser imposible de adivinar (un enlace para restablecer la contraseña, un código de invitación, un identificador de sesión), v4. Esa es toda la decisión, y la mayoría de la gente nunca se entera de que había una, porque casi todos los generadores solo ofrecen v4.

Porque es completamente aleatorio, y el índice de una base de datos está ordenado. Las claves aleatorias nuevas caen en lugares aleatorios del índice, así que cada inserción toca una página distinta, la caché deja de ayudar, y el índice se fragmenta y crece. En una tabla grande y con mucha actividad, eso es una ralentización medible que empeora con el tiempo. No es una preocupación teórica: es la razón por la que la documentación de Postgres y la de MySQL ya lo tratan.

Un UUID cuyos primeros 48 bits son una marca de tiempo en milisegundos, seguida de aleatoriedad. Sigue siendo único a nivel global y sigue teniendo 128 bits, pero como el tiempo va primero, los UUID v7 se ordenan en el orden en que se crearon. Las claves nuevas se agregan al final del índice en lugar de dispersarse por él, que es exactamente como se comporta un entero autoincremental, pero con la unicidad de un UUID. Se estandarizó en la RFC 9562 en 2024 y es la recomendación actual para tablas nuevas.

Sí, incluso dentro del mismo milisegundo, que es la parte que la mayoría de las implementaciones hace mal. Una marca de tiempo solo tiene resolución de milisegundos, así que generar mil ID en un bucle termina dentro de uno solo, y con bits bajos puramente aleatorios esos mil NO quedan en el orden en que se crearon. Este generador usa el contador monótono que describe la RFC 9562, así que un lote queda en orden estrictamente ascendente, siempre. Genera mil y ordénalos: vuelven en el orden en que se crearon.

Con una cosa en mente: revela cuándo se creó, al milisegundo, por diseño. Para una clave de base de datos eso suele ser inofensivo o incluso útil. Pero si el momento de creación es en sí un dato sensible, o si necesitas que el identificador sea imposible de adivinar, usa v4: v7 sigue teniendo 74 bits aleatorios, que es muchísimo, pero su marca de tiempo la puede leer sin problema cualquiera que tenga el ID.

Sí. La aleatoriedad viene de `crypto.getRandomValues`, el generador criptográficamente seguro del navegador, nunca de `Math.random`. Esa diferencia ha causado vulnerabilidades reales: `Math.random` es rápido pero predecible, y se han adivinado en la práctica tokens de sesión basados en él. Un UUID v4 tiene 122 bits aleatorios, suficiente para que las colisiones no sean una preocupación práctica.

Sí, por completo, y con identificadores eso importa. Un UUID obtenido del servidor de otra persona es un UUID que otra persona ya vio, lo que anula el propósito si estás generando un secreto. Estos nunca salen de tu navegador. Una vez que la página haya cargado, desactiva el wifi y funciona exactamente igual. Es la forma más sencilla de comprobar por ti mismo lo que decimos sobre privacidad, en lugar de creernos.

Todo ceros: 00000000-0000-0000-0000-000000000000. Es un UUID válido y reservado que se usa para indicar “ninguno” o “sin definir” donde no se puede usar null. Su opuesto, el UUID máximo, todo f, se usa a veces como centinela de ordenación. Ambos se ofrecen aquí porque de vez en cuando hacen falta y es incómodo escribirlos correctamente.