UUID vs NanoID

Anatomía: qué hay dentro de cada ID

Los UUID codifican sus propios metadatos. Los bits 48–51 guardan la versión —1 para tiempo más MAC, 4 para aleatorio, 7 para aleatorio ordenado por tiempo— y dos bits más fijan la variante. Una v4 siempre parece aleatoria; una v7 empieza con una marca de tiempo legible, porque sus primeros 48 bits son milisegundos desde el epoch de Unix y los UUID acuñados el mismo día comparten prefijo.

Los NanoID no llevan metadatos. Cada carácter es un sorteo independiente del alfabeto, elegido con enmascaramiento y muestreo por rechazo sobre crypto.getRandomValues, de modo que cada símbolo mantiene la misma probabilidad. Esa pureza es la razón por la que el formato es flexible —cambia el alfabeto o la longitud, conserva el algoritmo— y por la que un NanoID no revela nada sobre cuándo se creó.

La matemática de las colisiones: por qué ninguno colisiona nunca

La cota del cumpleaños dice que un identificador aleatorio de n bits alcanza una probabilidad de colisión del 50 por ciento cerca de 2^(n/2) sorteos. Para UUID v4 eso ronda 2^61 —unos 2,3 quintillones de IDs— antes de que las probabilidades de un solo duplicado lleguen a la mitad; los 126 bits de NanoID empujan la barra un poco más allá. En la práctica, ambos son sistemas de «esto no pasa nunca»: cualquier duplicado que te encuentres es un bug de código, no un evento de entropía.

Esa equivalencia es la razón por la que el debate del tamaño importa menos de lo que se asume: 21 caracteres de NanoID no son más seguros que un UUID v4 —la misma garantía en menos bytes—. Las razones honestas para elegir son el encaje operativo —almacenamiento, URL, herramientas—, no el riesgo de colisión.

Bases de datos: el problema de la localidad en el índice

Inserta una clave aleatoria en un índice B-tree y la fila puede caer en cualquier página; llena páginas a medias en orden aleatorio y cada inserción arriesga una división de página, escrituras extra y una caché más fría. Ese es el impuesto de fragmentación que pagan tanto UUID v4 como NanoID —NanoID incluido, porque es igual de aleatorio—. En una clave primaria indexada con carga intensa de escritura, por defecto ninguno es amable con el índice.

UUID v7 es la corrección que viene de serie dentro del estándar: sus primeros 48 bits son una marca de tiempo en milisegundos, así que las claves nuevas casi siempre se ordenan hacia el borde derecho del índice. NanoID no puede ofrecer esto: sin componente temporal, nada por lo que ordenar. En una columna indexada, la elección real es la v7 contra todo lo demás.

• v4 y NanoID dispersan las inserciones por el árbol —divisiones de página y fallos de caché a escala—.
• El tipo uuid de Postgres almacena 16 bytes en bruto; una clave de texto de 36 caracteres almacena 37 o más.
• La ventaja textual de NanoID —21 caracteres contra 36— solo se sostiene mientras el alfabeto permanezca documentado.

URL, alfabetos y el dial de longitud

El alfabeto de NanoID es seguro para URL por construcción: A-Za-z0-9_- no necesita codificación porcentual en ningún punto de una URL, así que un ID puede ser un segmento de ruta, un valor de consulta o un slug sin escapar nada. Los UUID también son técnicamente seguros para URL —los dígitos hexadecimales y los guiones nunca necesitan codificación—, pero 36 caracteres son mucha cadena visible para un enlace.

El alfabeto personalizado es la característica más práctica de NanoID: códigos solo numéricos, enlaces cortos en minúsculas —cambia los 64 símbolos, conserva el algoritmo—. Respeta la regla de que la entropía es la longitud por el log2 del tamaño del alfabeto: un NanoID en minúsculas de 8 caracteres ronda los 38 bits, razonable para un código de una hora, temerario como clave primaria. Los UUID no ofrecen ese dial; el formato está fijado en 128 bits.

Cuándo elegir cada uno

Elige UUID cuando el ID vive en la infraestructura: claves primarias de base de datos (v7), intercambio entre equipos y proveedores, cualquier cosa que un tercero deba validar, cualquier sitio donde lo integrado le gane a una dependencia. El estándar es el producto: todos los lenguajes, ORM y bases de datos ya lo hablan.

Elige NanoID cuando el ID es visible para el usuario: URL cortas, enlaces de invitación, nombres de archivo, valores de cookie, IDs de petición en los logs. La recomendación se invierte con la misma claridad: si sigues peleándote con lo ancho de un UUID dentro de una URL, ese enlace quiere NanoID; si te descubres reimplementando NanoID en un backend cuya base de datos podría servir claves de forma nativa, esa columna quiere un UUID v7.