La respuesta corta
Elige UUID v7 para nuevas claves de bases de datos, identificadores de eventos, entradas de registro y nombres de archivo que quieras en orden cronológico. Los v7 nuevos siempre son mayores que los anteriores, así que se añaden al final del índice como un número autoincremental, y aun así puedes crearlos en cualquier servidor o en el navegador sin consultar a la base de datos.
Elige UUID v4 para tokens, identificadores públicos cuya fecha de creación deba ser privada y sistemas que ya lo usan. Un v4 no revela nada, y en la mayoría de aplicaciones que no guardan millones de filas su orden aleatorio cuesta poco. Ambas versiones están definidas en el RFC 9562, publicado en 2024, que sustituyó al antiguo RFC 4122 y añadió las versiones 6, 7 y 8.
Pruébalo aquí: Generador de UUID v7
Abrir la herramienta completaCómo está formado un UUID
Todo UUID son 128 bits escritos como 32 dígitos hexadecimales en cinco grupos: 8-4-4-4-12, en total 36 caracteres con guiones. En todo UUID moderno hay dos campos fijos. El primer dígito del tercer grupo es la versión y se lee de un vistazo: 4 para aleatorio, 7 para tiempo Unix. El primer dígito del cuarto grupo es la variante y siempre es 8, 9, a o b en los UUID estándar.
Ejemplo v4: 9b2f4c1e-3a7d-4e8b-a5c2-0f6d1e9a3b47. Ejemplo v7: 019a2b3c-4d5e-7f60-8a1b-2c3d4e5f6a7b. En el ejemplo v7 los primeros 12 dígitos hexadecimales (019a2b3c4d5e) son el momento de creación en milisegundos; por eso los identificadores creados con un segundo de diferencia comparten casi todo el comienzo.
| Parte | UUID v4 | UUID v7 |
|---|---|---|
| Tamaño total | 128 bits | 128 bits |
| Timestamp | Ninguno | 48 bits, tiempo Unix en milisegundos |
| Versión y variante | 6 bits (versión 4) | 6 bits (versión 7) |
| Bits aleatorios | 122 | 74 (12 pueden usarse como contador) |
| Orden | Aleatorio | Por momento de creación |
| Revela cuándo se creó | No | Sí, al milisegundo |
| El timestamp alcanza hasta | No aplica | Aproximadamente el año 10889 |
Por qué v7 es más rápido como clave primaria
La mayoría de las bases de datos guardan la clave primaria en un índice B-tree ordenado por esa clave. Con claves v4 aleatorias, cada inserción cae en un lugar al azar del árbol. Cuando el índice ya no cabe en memoria, las inserciones leen páginas antiguas del disco una y otra vez, las páginas se dividen a medio llenar y el índice crece más de lo necesario. En InnoDB (MySQL y MariaDB) la propia tabla se guarda en el orden de la clave primaria, así que sufre toda la tabla, no solo el índice.
Con claves v7 las filas nuevas van al borde derecho del índice, las páginas activas se quedan en memoria y se llenan por completo. Las pruebas publicadas por fabricantes y usuarios de bases de datos suelen mostrar inserciones notablemente más rápidas e índices más pequeños que con v4 en tablas grandes, aunque la mejora exacta depende del motor, del tamaño de fila y del hardware. Las consultas por rango, como los últimos 100 pedidos, también salen más baratas porque las filas recientes están juntas.
Guarda los UUID en un tipo nativo de 16 bytes cuando exista (uuid en PostgreSQL, BINARY(16) en MySQL, uniqueidentifier en SQL Server) y no como texto de 36 caracteres. Las claves de texto ocupan más del doble y se comparan más despacio.
Notas por base de datos: PostgreSQL, MySQL, SQL Server, .NET
- PostgreSQL: el tipo uuid se ordena byte a byte, así que se conserva el orden de v7. PostgreSQL 18 añadió la función uuidv7(); en versiones anteriores la aplicación puede generar el valor.
- MySQL y MariaDB: guarda como BINARY(16) con UUID_TO_BIN(valor) sin el flag de intercambio, lo que conserva el orden de v7. La función UUID() de MySQL genera la versión 1, no la 7.
- SQL Server: uniqueidentifier compara primero el último grupo de bytes, así que ahí los v7 no quedan en orden de tiempo. Si necesitas claves secuenciales en SQL Server, NEWSEQUENTIALID() o una identidad bigint suelen ser opciones más simples.
- .NET: Guid.NewGuid() devuelve v4. Desde .NET 9, Guid.CreateVersion7() devuelve v7.
- JavaScript: crypto.randomUUID() en navegadores y Node.js devuelve v4; para v7 hace falta una biblioteca o una pequeña función como la que usa el generador de esta página.
Probabilidad de colisión en números reales
Con 122 bits aleatorios, una colisión de v4 es un problema del cumpleaños. Harían falta unos 2,7 trillones (2,7 x 10^18) de UUID para tener un 50 por ciento de probabilidad de un solo duplicado, es decir, mil millones de identificadores nuevos por segundo durante unos 86 años. Un generador aleatorio defectuoso, copias de máquinas virtuales o errores que reutilizan un valor son causas de duplicados mucho más realistas que el azar.
Un v7 tiene menos bits aleatorios, pero solo necesitan ser únicos dentro del mismo milisegundo. Ni siquiera un servicio que genere un millón de identificadores en un milisegundo corre un riesgo práctico. Los generadores además llevan un contador dentro del milisegundo, como este, para que los identificadores creados en lote sigan estrictamente ordenados.
Aun así, mantén siempre una restricción de unicidad en la columna. No cuesta nada y convierte un hecho casi imposible en un error claro en lugar de datos corruptos.
UUID vs GUID y otras versiones
GUID (globally unique identifier) es el nombre que Microsoft da al UUID. Es el mismo valor de 128 bits; las herramientas de Windows suelen escribirlo en mayúsculas y a veces entre llaves, como {3F2504E0-4F89-41D3-9A0C-0305E82C3301}. Las opciones del generador (Mayúsculas, Guiones, Llaves) cubren estos estilos.
La versión 1 combina un timestamp con la dirección de la tarjeta de red y hoy casi no se recomienda porque puede identificar la máquina. La versión 6 es la 1 reordenada para que se ordene por tiempo. Las versiones 3 y 5 se derivan de un nombre con MD5 o SHA-1, así que la misma entrada siempre da el mismo UUID. La versión 8 queda libre para formatos propios. ULID es un formato popular fuera del estándar UUID con la misma idea que v7, pero v7 cabe en cualquier columna uuid existente.
Cuándo v7 no es buena idea
- Identificadores públicos cuya fecha de creación es sensible: un v7 en una URL revela cuándo se creó una cuenta, un pedido o un documento.
- Tokens, enlaces de invitación y códigos para restablecer contraseñas: usa v4 o un token aleatorio más largo, nunca algo que se pueda adivinar por la hora.
- Sistemas que ordenan o comparan identificadores con otro orden de bytes, como uniqueidentifier en SQL Server.
- Tablas existentes llenas de claves v4: mezclar versiones funciona, pero la ventaja del índice solo se nota en las filas nuevas.