Versiones de GUID explicadas: v1–v7 y cuál elegir

2026-07-09

Etiquetas: Windows · GUID · Guía · QuickGUID

---

Abre cualquier librería UUID y verás uuid1(), uuid3(), uuid4(), uuid5() y cada vez más uuid7(). La especificación define ocho versiones. ¿Cuál usar realmente?

La respuesta corta: v4 para casi todo, v7 para claves primarias de base de datos, v5 cuando necesitas que la misma entrada produzca siempre el mismo GUID. El resto de este artículo explica por qué — con disposiciones de bytes, las razones reales de cada versión y una chuleta de código por lenguaje.

Si eres nuevo con los GUID, empieza por ¿Qué es un GUID? para lo básico de estructura y unicidad. Este artículo es el compañero técnico — profundiza en cada versión.

El panorama de versiones de GUID/UUID

Cada versión es una receta distinta para rellenar los mismos 128 bits. El nibble de versión (primer dígito hex del tercer segmento) te indica qué receta se usó.

Versión	Fuente de generación	Ordenable	Uso típico
v1	Tiempo + MAC	Sí	Sistemas heredados (riesgo de privacidad)
v2	DCE Security	Sí	Raro, especializado
v3	Hash de namespace MD5	No	Obsoleto (usa v5)
v4	Aleatorio	No	Predeterminado general
v5	Hash de namespace SHA-1	No	IDs deterministas
v6	Tiempo v1 reordenado	Sí	Reemplazo directo de v1
v7	Marca de tiempo en milisegundos	Sí	Claves primarias de base de datos
v8	Definido por el fabricante	Personalizado	Especializado

Las versiones v1, v4, v5 y v7 cubren el 99 % del uso real. Repasémoslas.

v1: Tiempo y dirección MAC

v1 es la receta original de RFC 4122. Empaqueta tres cosas en 128 bits:

| time_low (32) | time_mid (16) | ver+time_hi (16) | var+clk_seq (16) | node/MAC (48) |

• Marca de tiempo de 60 bits — intervalos de 100 nanosegundos desde el 15/10/1582 (fecha de adopción del calendario gregoriano). La marca de tiempo se reparte entre time_low, time_mid y time_hi.
• Secuencia de reloj de 14 bits — un contador que desambigua dos GUID generados en el mismo tick de reloj, o cuando el reloj del sistema se retrocedió.
• Nodo de 48 bits — la dirección MAC de la tarjeta de red.

El problema de la dirección MAC

El campo nodo es una huella de hardware. Cualquier GUID v1 que publiques transporta la dirección MAC de tu máquina — y a diferencia de una dirección IP, una dirección MAC está pensada para ser globalmente única y persistente. Es una fuga de privacidad real.

No es teórico. Investigadores han demostrado que se puede rastrear documentos hasta la máquina que los creó leyendo los GUID v1 incrustados en los metadatos del archivo. El propio Microsoft eliminó la generación v1 de la telemetría de Office tras demostrarse esto. Los sistemas operativos modernos también aleatorizan la MAC mostrada a las redes Wi-Fi por la misma razón.

Veredicto: evita v1 en código nuevo. Sobrevive en sistemas heredados, interfaces COM y algunas herramientas cercanas al hardware — pero no hay razón para generarlo tú mismo hoy.

v2: DCE Security

v2 es la versión que básicamente nunca encontrarás. Toma la disposición de v1 (marca de tiempo + MAC) y le superpone un UID/GID POSIX — los identificadores locales de usuario y grupo del modelo de seguridad DCE (Distributed Computing Environment) — para que el UUID pueda llevar información de control de acceso además de su unicidad.

v2 existe para autenticación DCE/RPC y ACLs en sistemas empresariales heredados. A menos que mantengas software que hable explícitamente DCE Security, nunca generarás ni consumirás un v2. Aparece aquí únicamente para que la lista de versiones esté completa y no te quedes preguntándote qué significa un «2» en ese nibble si alguna vez lo encuentras.

v3: Por qué quedó obsoleto

v3 es idéntico a v5 salvo en que usa MD5 en lugar de SHA-1. MD5 tiene ataques de colisión prácticos — se pueden diseñar dos entradas distintas que produzcan el mismo hash. Eso rompe la garantía de determinismo de v3 en escenarios adversariales.

RFC 4122 conservó v3 por retrocompatibilidad pero v5 lo reemplazó. No hay razón para generar v3 hoy. Si te encuentras un v3 en el mundo real, trátalo como heredado.

v4: El predeterminado aleatorio

v4 es lo que obtienes de prácticamente cualquier llamada «generar un GUID»: [guid]::NewGuid(), Guid.NewGuid(), crypto.randomUUID(), uuid.uuid4(), NEWID(). Rellena 122 de los 128 bits con aleatoriedad criptográficamente fuerte (los otros 6 bits son los marcadores de versión y variante).

Sin marca de tiempo, sin MAC, sin estado de máquina — aleatoriedad pura. Eso hace que v4 sea seguro de exponer, trivialmente paralelizable y suficientemente resistente a colisiones para cualquier carga realista. Para la matemática completa de colisiones (y por qué la afirmación viral de «mil millones de años» entiende mal la paradoja del cumpleaños), consulta el artículo principal.

Veredicto: este es tu predeterminado. Elige v4 salvo que tengas una razón específica para elegir otra cosa.

v5: IDs de namespace deterministas

Esta es la versión de la que la mayoría de desarrolladores ha oído hablar pero nunca ha usado — y resuelve un problema genuinamente útil.

v5 te permite derivar el mismo GUID de la misma entrada, siempre. Entrégale un UUID de namespace y una cadena de nombre, y devuelve un identificador determinista:

import uuid

# Misma entrada → mismo GUID, en cada ejecución, en cada máquina
dns_guid = uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')
url_guid = uuid.uuid5(uuid.NAMESPACE_URL, 'https://prunelab.net/blog/guid-explained')

print(dns_guid)  # siempre  cf14e0a3-... (mismo valor)
print(dns_guid == uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com'))  # True

Cómo funciona

Internamente, v5 concatena los bytes del UUID de namespace con los bytes UTF-8 del nombre, ejecuta SHA-1 sobre el resultado, toma los primeros 16 bytes y luego estampa los bits de versión (5) y variante. El namespace en sí es un UUID — NAMESPACE_DNS, NAMESPACE_URL, NAMESPACE_OID y NAMESPACE_X500 están predefinidos, pero puedes usar cualquier UUID como namespace.

Cuándo v5 es la herramienta adecuada

• Fixtures de prueba reproducibles — genera IDs para datos de prueba que se mantienen estables entre ejecuciones, para que un test que falla apunte siempre a la misma entidad.
• Identificadores derivados de URL — convierte una URL en un GUID sin consulta a la base de datos. Dos sistemas que calculan independientemente uuid5(NAMESPACE_URL, url) para la misma URL siempre coinciden.
• Desduplicación idempotente — importa el mismo registro dos veces y el GUID colisiona consigo mismo, así que puedes detectar el duplicado solo por la clave.

El contraste clave con v4: v4 devuelve un valor único por llamada (incluso para entradas idénticas); v5 devuelve un valor estable para entradas idénticas. No son intercambiables.

Veredicto: recurre a v5 siempre que necesites un GUID que se derive de forma reproducible a partir de una cadena de entrada.

v6: El arreglo de v1 que probablemente no necesitas

v6 contiene exactamente los mismos datos que v1 — la misma marca de tiempo, secuencia de reloj y MAC — pero reorganiza los bits de marca de tiempo para que el valor se ordene de forma natural en orden cronológico. En v1 la marca de tiempo está dividida de forma torpe (low, mid, high); en v6 se almacena high-first, así que la ordenación lexicográfica de cadenas equivale a la ordenación temporal.

v6 se estandarizó en 2024 en la RFC 9562 junto a v7. Existe principalmente como ruta de migración directa para sistemas ya atados al modelo reloj-y-MAC de v1: mantienes tu lógica de marca de tiempo existente y simplemente reescribes la disposición de bits.

Para sistemas nuevos, v7 es casi siempre la mejor opción. v7 usa una marca de tiempo en milisegundos (más simple que el conteo gregoriano de 100 ns de v1/v6), no incrusta una dirección MAC y tiene un relleno aleatorio más limpio. v6 responde a «cómo modernizo v1 sin cambiar mi modelo de generación»; v7 responde a «qué debería usar de ahora en adelante».

v7: Ordenado en el tiempo para bases de datos

v7 es la incorporación más importante desde v4. Resuelve un problema que v4 crea en bases de datos.

El problema de v4 en bases de datos

Cuando una base de datos usa GUIDs como claves primarias, esas claves sostienen un índice de árbol B+. Los árboles B+ se mantienen eficientes cuando las inserciones están aproximadamente ordenadas — los valores nuevos caen en el borde derecho y rellenan las páginas existentes. Los GUID v4 aleatorios se esparcen por todo el espacio de claves, así que cada inserción golpea una página aleatoria. En tablas grandes esto provoca divisiones de página constantes, fragmentación de índice, thrash de caché y amplificación de escritura. El arreglo en SQL Server (NEWSEQUENTIALID()) es un hack propietario y no portable que filtra la secuenciación.

La disposición de v7

| unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62) |

• Marca de tiempo Unix de 48 bits en milisegundos — campo inicial, así que los valores aumentan con el tiempo.
• Versión de 4 bits — puesta a 7.
• rand_a de 12 bits — aleatorio, u opcionalmente un contador monótono para ordenar dentro del mismo milisegundo.
• Variante de 2 bits — el marcador RFC 9562 estándar.
• rand_b de 62 bits — aleatorio.

Como la marca de tiempo va primero, los GUID v7 generados en secuencia están ordenados de forma natural: las inserciones de índice se agrupan en el borde derecho, las páginas se rellenan limpiamente, y el árbol B+ se comporta como con un entero autoincremental — y sigue siendo globalmente único sin coordinador central.

Cuándo v7 NO merece la pena

• Stores en memoria (Redis, memcached) — sin árbol B+, sin coste de fragmentación. v4 basta.
• Tablas pequeñas — la diferencia entre v4 y v7 es invisible por debajo de millones de filas.
• Columnas que no son clave — si el GUID es solo un atributo almacenado y no una clave de índice, el orden es irrelevante.
• GUIDs que deben ser opacos — v7 filtra el milisegundo de generación, lo que puede ser indeseable en contextos sensibles a la seguridad.

Veredicto: si un GUID es una clave primaria agrupada en una base de datos real, usa v7. En caso contrario v4.

v8: Definido por el fabricante

v8 es la salida de emergencia: la RFC 9562 deja que el fabricante defina su propia disposición de bits, siempre que el nibble de versión sea 8 y los bits de variante sean correctos. Todo lo demás — ancho de marca de tiempo, fuente de aleatoriedad, codificación — lo decide el implementador.

Solo verás v8 en sistemas que diseñaron un esquema UUID personalizado por una razón específica (por ejemplo, integrar un shard ID o node ID en el UUID para enrutamiento). Si no estás construyendo ese tipo de sistema, v8 es irrelevante; y si lo estás, las reglas son las de tu propio esquema, no las de este artículo.

¿Qué versión deberías usar realmente?

Una guía de decisión:

• «¿Generar IDs para uso general?» → v4. Esta es la respuesta en el 90 % de los casos.
• «¿Clave primaria de base de datos o necesito orden temporal?» → v7. Especialmente para índices agrupados en tablas grandes.
• «¿Necesito el mismo GUID para la misma entrada siempre?» → v5. Mapeo determinista desde una cadena.
• «¿Trabajas con un sistema heredado que espera v1?» → v1 (mantén compatibilidad), pero planifica una migración a v7.
• «¿Alguien me dijo que use v3?» → No. Usa v5 en su lugar (MD5 en v3 está roto).
• «Quiero lo más nuevo.» → No es una razón. v7 es nuevo y resuelve un problema real (orden en BD); v6 es nuevo y sobre todo una ayuda de migración de v1. Elige por caso de uso, no por novedad.

Si sigues sin estar seguro, usa v4. El predeterminado existe por una razón.

Generar GUIDs por versión y lenguaje

Lenguaje / herramienta	v4 (predeterminado)	v5 (determinista)	v7 (ordenado)
PowerShell	[guid]::NewGuid()	—	—
C# / .NET	Guid.NewGuid()	—	Guid.CreateVersion7() (.NET 9+)
Python	uuid.uuid4()	uuid.uuid5(uuid.NAMESPACE_URL, 'name')	uuid.uuid7() (3.14 beta) / lib
JavaScript	crypto.randomUUID()	—	(npm uuid v11+)
Node.js (lib uuid)	uuid.v4()	uuid.v5('name', NAMESPACE)	uuid.v7()
SQL Server	NEWID()	—	—
PostgreSQL	gen_random_uuid()	—	(extensión)

Algunas notas: el soporte nativo de v7 aún está aterrizando en las librerías estándar en 2026. El paquete uuid de Node.js (v11+) y .NET 9 lo entregan nativamente; Python añade uuid.uuid7() en 3.14; los runtimes más antiguos necesitan una librería. El soporte de v5 es casi universal porque es pura matemática SHA-1 sin fuente de entropía requerida.

Preguntas frecuentes

¿Reemplazará v7 a v4 como predeterminado?

No. v4 sigue siendo el predeterminado general. v7 solo gana cuando el GUID es una clave primaria ordenada — para la mayoría de los otros usos (tokens de sesión, IDs de petición, hashes de contenido, todo lo que no es base de datos) la aleatoriedad de v4 no es un inconveniente, y la marca de tiempo inicial de v7 solo filtraría información de timing sin beneficio.

¿Es v1 todavía seguro de usar?

No. v1 incrusta la dirección MAC de tu tarjeta de red, que es una huella de hardware persistente. El propio Microsoft eliminó v1 de la telemetría de Office tras que investigadores rastrearan máquinas a través de documentos por GUIDs incrustados. Para código nuevo, evita v1 por completo; para v1 heredado, planifica una migración a v7.

¿Cuál es la diferencia entre v3 y v5?

Ambos son hashes de namespace deterministas (misma entrada → mismo GUID). v3 usa MD5, v5 usa SHA-1. MD5 tiene ataques de colisión prácticos, así que v3 se considera roto para fines de integridad y fue reemplazado por v5. No hay razón para generar v3 hoy.

¿Puedo convertir un GUID v4 a v7?

No. La versión no es una etiqueta que puedas intercambiar — cada versión usa una lógica de generación completamente distinta. v4 no tiene marca de tiempo que extraer, así que la única forma de «obtener un v7» es generar uno nuevo. Si necesitas migrar una columna de clave primaria v4 a v7, en realidad estás añadiendo una columna nueva y reescribiéndola.

¿.NET soporta v7 nativamente?

Sí. Guid.CreateVersion7() se añadió en .NET 9 (publicado en noviembre de 2024). Si estás en .NET 8 o anterior, usa los paquetes NuGet GenVault o UUIDv7, o actualiza.

QuickGUID: genera v4 y v7, convierte cualquier formato

Para el trabajo diario con GUIDs, QuickGUID es una caja de herramientas nativa de Windows que cubre todo el flujo:

• Generación por lotes de v4 o v7, hasta 1.000 a la vez
• Conversión de 10+ formatos: estándar, sin guiones, llaves, Base64, array de bytes en C, macro DEFINE_GUID — todo con vista previa en directo
• Extracción inteligente: pega logs o código fuente, encuentra y convierte automáticamente cada GUID
• Decoradores en directo: comillas, prefijos/sufijos, mayúsculas/minúsculas — alterna globalmente y copia directamente

Totalmente gratuito, 100% offline.

Para cerrar

El sistema de versiones existe porque distintos trabajos necesitan garantías distintas: v4 te da aleatoriedad no rastreable, v5 te da reproducibilidad, v7 te da orden. Por defecto v4, recurre a v7 en claves de base de datos, y usa v5 cuando entradas idénticas deban producir GUIDs idénticos.

¿Nuevo con los GUID? Empieza con ¿Qué es un GUID? para lo básico de estructura, el formato con guiones y por qué 128 bits bastan para hacer de las colisiones un asunto irrelevante en la práctica.