UUID v4 explicado: por qué los IDs aleatorios ganan al autoincremental

Qué es realmente un UUID v4, por qué el riesgo de colisión es prácticamente nulo, y las situaciones concretas en las que gana a un simple ID entero autoincremental.

Un UUID v4 es un identificador de 128 bits generado casi enteramente a partir de bits aleatorios, formateado como 32 caracteres hexadecimales divididos en 5 grupos (p. ej. 3fa85f64-5717-4562-b3fc-2c963f66afa6). El '4' marca la versión, y significa que el ID no lleva ninguna información sobre cuándo, dónde o por qué se creó — que es precisamente el objetivo.

¿No hay riesgo de que colisionen dos IDs?

Técnicamente sí, en la práctica no. Un UUID v4 tiene 122 bits aleatorios (6 bits están fijados para marcar versión y variante), lo que da unos 5,3 x 10^36 valores posibles. Necesitarías generar aproximadamente 2,71 trillones de UUIDs antes de tener un 50% de probabilidad de una sola colisión. Para prácticamente cualquier aplicación real, ese riesgo es menor que la probabilidad de que un fallo de hardware corrompa los datos de todos modos.

¿Por qué no usar simplemente 1, 2, 3… como un autoincremental de base de datos?

Un entero autoincremental funciona bien dentro de una única base de datos, pero filtra información y se rompe en cuanto tu sistema crece. Los IDs secuenciales permiten a cualquiera adivinar registros vecinos con solo cambiar un número en una URL (/pedidos/1042 → /pedidos/1043), revelan tu volumen aproximado de registros o pedidos a la competencia, y no se pueden generar de forma segura desde dos servidores distintos a la vez sin un contador compartido — que se convierte en un cuello de botella en cuanto escalas horizontalmente.

Cuándo un UUID es claramente la mejor opción

Cualquier sistema con varios escritores independientes (microservicios, apps móviles offline-first, bases de datos distribuidas) es el que más se beneficia, ya que cada nodo puede generar un ID válido y único con cero coordinación y cero contador central. También es la decisión correcta siempre que un ID pueda acabar siendo visible para el usuario — referencias de pedido, IDs de recursos de API, nombres de archivo — donde no quieres que sea adivinable ni que revele información de secuencia.

Cuándo un entero sigue siendo la mejor opción

Para una aplicación pequeña con un único escritor donde los IDs nunca salen de la base de datos y necesitas el menor espacio de almacenamiento posible y las búsquedas de índice más rápidas, un simple entero autoincremental (o su primo ordenado, UUID v7) sigue siendo más simple y rápido. La aleatoriedad del UUID v4 es también su principal desventaja para indexar: al no estar ordenados los valores, fragmentan un índice B-tree mucho más que un ID secuencial.

Nuestro generador de UUID produce UUIDs v4 válidos y conformes a RFC 4122 al instante y en lote, completamente en tu navegador — útil para fixtures de test, datos simulados, o simplemente elegir un ID único seguro sin levantar una base de datos.