Guía de UUID: v4 frente a v7 y UUID como claves primarias

Qué es un UUID

Un UUID (Universally Unique Identifier) es un identificador de 128 bits que permite a cualquiera crear ID que no choquen sin consultar a un servidor central. Microsoft lo llama GUID. El estándar actual es la RFC 9562, publicada en 2024.

Se escribe como 32 dígitos hexadecimales separados por guiones en grupos 8-4-4-4-12, 36 caracteres en total. El primer dígito del tercer grupo indica la versión: xxxxxxxx-xxxx-4xxx-... es v4 y 7xxx es v7.

Las versiones de un vistazo

Hoy lo habitual es elegir v4 para uso general y v7 cuando importan el orden y el rendimiento de inserción, como en las claves primarias de una base de datos.

• v1: combina una marca de tiempo con la dirección MAC de la máquina. Ordenada en el tiempo, pero puede filtrar información del hardware.
• v3 y v5: aplican hash a un espacio de nombres y un nombre, así que la misma entrada siempre da el mismo UUID (v3 usa MD5, v5 usa SHA-1).
• v4: 122 bits aleatorios. La más usada y la más sencilla de implementar.
• v7: una marca de tiempo Unix de 48 bits en milisegundos seguida de bits aleatorios. Se ordena por fecha de creación.

¿De verdad no pueden coincidir los UUID?

La parte aleatoria de un UUID v4 tiene 122 bits, lo que da unos 5,3 × 10^36 valores posibles. Por la paradoja del cumpleaños, harían falta unos 2,7 × 10^18 UUID para tener un 50 % de probabilidad de un solo duplicado: aproximadamente mil millones por segundo durante 85 años. En la práctica, las colisiones no ocurren.

Eso solo es cierto si los números aleatorios son realmente aleatorios. Se han registrado duplicados al clonar máquinas virtuales con el mismo estado del generador aleatorio, o con implementaciones caseras que usaban funciones aleatorias predecibles. Usa la función UUID estándar de tu plataforma.

UUID como claves primarias

Las claves UUID pueden generarse en muchos servidores a la vez y no revelan cuántos registros existen. Con enteros autoincrementales, una URL como /orders/1052 permite a la competencia estimar tu volumen de pedidos.

Los inconvenientes son el tamaño y el orden. Un UUID ocupa 16 bytes, el doble que un entero de 8 bytes, y más si se guarda como cadena de 36 caracteres. Como v4 es totalmente aleatorio, las filas nuevas caen en cualquier lugar de un índice B-tree, lo que provoca divisiones de página frecuentes y escrituras más lentas. v7 crece con el tiempo y evita en gran medida este problema.

• PostgreSQL: usa el tipo nativo uuid (16 bytes).
• MySQL: guárdalo como BINARY(16); la versión 8.0+ ofrece UUID_TO_BIN.
• SQL Server: usa el tipo uniqueidentifier.

Cuándo no usar un UUID como secreto

Un UUID está diseñado para ser un nombre único, no un secreto imposible de adivinar. v1 y v7 contienen una marca de tiempo, así que algunos bits son predecibles. Los valores sensibles, como los tokens de restablecimiento de contraseña y los secretos de API, deben generarse a partir de suficientes bytes aleatorios criptográficamente seguros.

Genera tantos UUID como necesites con el generador de UUID de AIBIZAP y usa el generador de credenciales de cliente para los secretos. Si diseñas tablas a partir de ejemplos JSON, el generador de DDL desde JSON es un buen complemento.