Toda base de datos moderna, sistema distribuido y API usa identificadores únicos — y en 2026, el estándar que los rige ha cambiado fundamentalmente. Un UUID (Universally Unique Identifier, identificador único universal) es una etiqueta de 128 bits que puede identificar información entre sistemas informáticos sin ninguna coordinación central. Bajo el nuevo RFC 9562 (que reemplazó a RFC 4122 en mayo de 2024), el panorama ha cambiado: UUID v4 sigue siendo la opción preferida para IDs aleatorios, pero UUID v7 es ahora el estándar recomendado para claves primarias de bases de datos, porque su estructura ordenada en el tiempo evita la fragmentación del índice en árbol B.
Esta guía cubre el panorama completo: cómo funcionan los UUID, qué versión usar en cada caso y cómo implementarlos correctamente.
Comprender RFC 9562: el estándar UUID moderno
Un UUID es un número de 128 bits cuya unicidad está prácticamente garantizada — sin necesidad de ninguna autoridad central. Según Wikipedia, la probabilidad de que dos UUID colisionen está tan cerca de cero que se considera imposible en aplicaciones reales. Distintos equipos pueden etiquetar datos de forma independiente, con la confianza de que sus IDs no chocarán.
En mayo de 2024, la IETF publicó el RFC 9562, retirando el antiguo RFC 4122. La actualización respondía a las exigencias de los sistemas distribuidos modernos, que necesitaban IDs tanto únicos como ordenables en el tiempo. Se introdujeron tres versiones nuevas: v6, v7 y v8.
Anatomía de un UUID: versiones y variantes
Normalmente verás un UUID como 32 caracteres hexadecimales divididos en cinco grupos por guiones (8-4-4-4-12):
550e8400-e29b-41d4-a716-446655440000
^
version
Dos campos clave te indican cómo se generó el UUID:
| Campo | Ubicación | Qué indica |
|---|---|---|
| Bits de versión | Los primeros 4 bits del 7.º byte (primer carácter del 3.º grupo) | Qué algoritmo se usó (p. ej., «4» = v4, «7» = v7) |
| Bits de variante | 9.º byte | La variante del UUID — RFC 9562 usa un patrón de bits 10 |
Como explica SnapUtils, los bits de variante separan los UUID modernos de RFC 9562 de los formatos antiguos de Apollo o Microsoft.
Por qué UUID v7 es el nuevo estándar de oro para bases de datos
El mayor inconveniente de UUID v4 es que es completamente aleatorio. Cuando se usa como clave primaria en un índice de árbol B, la base de datos tiene que insertar filas nuevas en posiciones impredecibles. Según CreateUUID, esto provoca «divisiones de página» (page splits) — la base de datos debe reorganizar constantemente los datos para hacer espacio, lo que ralentiza las escrituras y desperdicia memoria.
UUID v7 lo resuelve colocando una marca de tiempo Unix Epoch de 48 bits (precisión de milisegundos) al inicio del ID. Esto hace que los IDs sean monótonamente crecientes — los nuevos siempre son mayores que los antiguos. La base de datos puede simplemente añadir al final del índice, dándote el rendimiento de un entero secuencial con la unicidad global de un UUID.
Cómo UUID v7 equilibra tiempo y entropía
UUID v7 rellena los 74 bits restantes con un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Según Wikipedia, necesitarías generar unos 1.000 millones de UUID por segundo durante 85 años para alcanzar una probabilidad de colisión del 50 %. Para cualquier aplicación real, UUID v7 es efectivamente a prueba de colisiones.
Mejores prácticas de almacenamiento: Binary(16) vs. String(36)
Cómo almacenas los UUID importa tanto como la versión que uses:
| Formato de almacenamiento | Espacio | Rendimiento del índice | Recomendación |
|---|---|---|---|
| Binary(16) | 16 bytes | Alto (compacto) | Mejor práctica |
| Tipo UUID nativo | 16 bytes | Alto (optimizado) | Ideal para PostgreSQL |
| Cadena (Char 36) | 36–72 bytes | Bajo (fragmentado) | Evitar |
SnapUtils recomienda usar siempre tipos nativos en lugar de cadenas. En PostgreSQL, el tipo nativo uuid almacena los datos en un formato binario compacto de 16 bytes y a la vez admite consultas estándar basadas en cadenas.
UUID vs. GUID: ¿hay alguna diferencia?
Un GUID (Globally Unique Identifier, identificador único global) es la implementación de Microsoft del estándar UUID. Históricamente había una diferencia en el orden de bytes (endianness) — los primeros GUID de Microsoft usaban little-endian para los tres primeros campos, mientras que los UUID estándar usaban big-endian (orden de bytes de red) (SnapUtils).
Para 2026, se trata sobre todo de una convención de nomenclatura. Bajo RFC 9562, funcionan de forma idéntica. Un Guid.NewGuid() en .NET es totalmente compatible con un uuid.uuid4() en Python. Oirás «GUID» en los círculos de Windows/Azure y «UUID» en las comunidades de Linux y de código abierto.
Implementar UUID modernos: lenguaje por lenguaje
| Lenguaje | UUID v4 | UUID v7 |
|---|---|---|
| Python | Módulo uuid integrado |
Paquete uuid6 o uuid7 |
| JavaScript | crypto.randomUUID() |
Paquete npm uuid (v10+) |
| PostgreSQL | gen_random_uuid() (PG 13+) |
uuidv7() nativo (PG 17+) o extensiones |
| .NET | Guid.NewGuid() |
Paquetes de la comunidad |
| Rust | crate uuid (v1.7+) |
crate uuid con la característica v7 |
IDs deterministas: UUID v5
Si necesitas el mismo ID cada vez para una entrada dada (como una URL o un nombre de usuario), usa UUID v5. Hashea un UUID de espacio de nombres y una cadena de nombre con SHA-1 — perfecto para la desduplicación cuando no puedes consultar una base de datos central.
La lección de privacidad de UUID v1
UUID v1 usa una marca de tiempo y la dirección MAC del ordenador. Se ha abandonado en gran medida porque filtra información del hardware. Un ejemplo famoso: el creador del virus Melissa fue atrapado porque los UUID en los documentos de Word infectados contenían su dirección MAC específica.
RFC 9562 avanzado: v6, v8 y UUID especiales
RFC 9562 añadió versiones especializadas para necesidades de nicho en sistemas distribuidos:
| Versión | Propósito | Cuándo usar |
|---|---|---|
| v6 | Marca de tiempo v1 reordenada — ordenable manteniendo la precisión de v1 | Migración de sistemas v1 heredados |
| v8 | Personalizado — 122 bits para datos definidos por el desarrollador | Esquemas experimentales o específicos del proveedor |
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
Marcador de posición nulo |
| Max UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
Marcador de extremo del rango |
Conclusión
RFC 9562 ha actualizado los identificadores únicos para la era cloud moderna. Las recomendaciones prácticas:
- Claves primarias de base de datos → Usa UUID v7 para inserciones ordenadas en el tiempo y sin fragmentación
- Aleatoriedad general → UUID v4 sigue siendo perfectamente válido
- Desduplicación → UUID v5 te da IDs deterministas
- Almacenamiento → Usa siempre Binary(16) o tipos UUID nativos, nunca cadenas
Acción: Revisa tus esquemas de base de datos. Si usas UUID v4 como clave primaria en tablas con millones de filas, migrar a UUID v7 es un cambio sencillo que puede reducir significativamente la fragmentación del índice y acelerar las consultas.
Preguntas frecuentes
¿Un UUID es lo mismo que un GUID?
Funcionalmente, sí. Un GUID es la implementación de Microsoft del estándar UUID. Bajo RFC 9562, son idénticos en comportamiento — puedes usarlos indistintamente entre aplicaciones .NET, Java y Python.
¿Pueden dos UUID colisionar alguna vez en un escenario real?
Matemáticamente posible, prácticamente imposible. Para UUID v4, necesitarías generar aproximadamente 2,71 trillones de IDs para alcanzar una probabilidad de colisión del 50 %. Según Generate-Random.org, generar 1.000 millones de UUID por segundo durante 85 años te da solo un 50 % de probabilidad de una única colisión.
¿Debo almacenar UUID como cadenas o como binario en mi base de datos?
Prefiere siempre Binary(16) o el tipo UUID nativo (disponible en PostgreSQL). Una cadena de 36 caracteres consume más del doble de espacio y ralentiza considerablemente las búsquedas en el índice y las uniones.SnapUtils señala que las ventajas de rendimiento de RFC 9562 se maximizan cuando el almacenamiento se mantiene compacto.
¿Cuándo debo usar UUID v5 en lugar de UUID v4?
Usa v5 cuando necesites IDs deterministas — la misma entrada produce siempre el mismo UUID, sin consultar una base de datos. Usa v4 cuando necesitas aleatoriedad total y quieres garantizar que el identificador no pueda ser retroingeniado a su origen.
