Que es un UUID y para que sirve
Un UUID (Universally Unique Identifier, Identificador Universalmente Unico) es un numero de 128 bits estandarizado por el RFC 4122, representado en este formato:
550e8400-e29b-41d4-a716-446655440000
Cinco grupos hexadecimales separados por guiones, siempre 36 caracteres. La version del UUID se indica en el tercer grupo (la cifra despues del segundo guion, en este caso 4).
Los UUID son la solucion estandar cuando necesita generar identificadores unicos sin coordinacion central: sin base de datos que los asigne, sin servidor que los controle. Son ideales para sistemas distribuidos, APIs REST, identificadores generados en el cliente antes de enviar una peticion, y claves de idempotencia.
Versiones de UUID: de v1 a v8
El RFC 9562 (actualizacion de 2022) define ocho versiones. Las mas relevantes para el desarrollo actual son:
UUIDv1 (basado en tiempo y MAC) Combina el timestamp actual con la direccion MAC de la maquina. Garantiza unicidad entre maquinas en el mismo instante, pero expone la identidad del servidor. En desuso por razones de privacidad.
UUIDv3 (basado en nombre, MD5) Deterministico: el mismo nombre en el mismo espacio de nombres genera siempre el mismo UUID. Usa MD5, considerado debil hoy en dia. Use v5 en su lugar.
UUIDv4 (aleatorio) Generado a partir de 122 bits de datos aleatorios. Es la version mas usada actualmente. La probabilidad de colision es practicamente nula: para generar una colision con una probabilidad del 50% necesitaria generar mas de 2,7 trillones de UUIDs. Uselo cuando no necesite ordenacion temporal.
UUIDv5 (basado en nombre, SHA-1) Como v3 pero con SHA-1. Preferido sobre v3 para proyectos nuevos cuando se necesita un ID deterministico por nombre.
UUIDv7 (aleatorio ordenado por tiempo) Introducido en el RFC 9562 de 2022. Esta es la opcion moderna para bases de datos.
UUIDv7 vs UUIDv4: por que importa para las bases de datos
Esta es la distincion mas importante para el desarrollo backend moderno.
El problema de UUIDv4 en bases de datos: Los UUIDs v4 son completamente aleatorios. Cuando se usan como clave primaria en una tabla con un indice B-tree (el tipo de indice por defecto en PostgreSQL, MySQL y SQLite), cada nuevo registro se inserta en una posicion aleatoria del arbol de indice. Esto obliga al motor de base de datos a reordenar el indice frecuentemente, degradando el rendimiento en tablas grandes.
La solucion de UUIDv7: El UUIDv7 combina un prefijo de timestamp de 48 bits con precision de milisegundo, seguido de bits aleatorios. Como el timestamp es creciente, los nuevos registros se insertan siempre al final del indice, igual que con un entero autoincremental.
| Caracteristica | UUIDv4 | UUIDv7 |
|---|---|---|
| Aleatoriedad | Completa | Parcial (sufijos aleatorios) |
| Ordenable cronologicamente | No | Si |
| Rendimiento en indices | Degradacion en tablas grandes | Optimo |
| Privacidad (sin MAC) | Si | Si |
| Soporte en bases de datos | Universal | Creciente (PG 17, MySQL 9+) |
Frameworks como Laravel 11 (muy popular en el ecosistema PHP hispanohablante) y Django ya soportan UUIDv7 de forma nativa o mediante paquetes.
ULID como alternativa al UUID para startups espanolas y LATAM
El ULID (Universally Unique Lexicographically Sortable Identifier) es otra alternativa popular, especialmente en el ecosistema de startups tecnologicas de Espana, Mexico y Argentina.
Un ULID tiene este aspecto:
01ARZ3NDEKTSV4RRFFQ69G5FAV
Caracteristicas del ULID:
- 26 caracteres (vs 36 del UUID con guiones)
- Solo usa caracteres Crockford Base32 (sin letras confusas como I, L, O, U)
- Ordenable lexicograficamente por tiempo (como UUIDv7)
- Compatible con URL sin codificacion adicional
El objetivo del ULID y del UUIDv7 es el mismo: unicidad global mas ordenacion temporal. La eleccion entre ellos depende principalmente del ecosistema de su proyecto y las librerias disponibles.
UUID y proteccion de datos: LOPDGDD en Espana y LGPD en Brasil
Este aspecto es relevante para cualquier equipo de desarrollo que maneje datos de usuarios espanoles o brasilenios.
Pseudonimizacion con UUID:
Tanto el RGPD europeo (y su implementacion espanola en la LOPDGDD) como la LGPD brasilena reconocen la pseudonimizacion como una tecnica que reduce el riesgo en el tratamiento de datos personales. La idea es sustituir un dato directamente identificable (un email, un DNI, un telefono) por un identificador que no permita identificar al usuario sin informacion adicional.
Un UUID asignado a un usuario puede ser un seudonimiazador valido si:
- La tabla que relaciona el UUID con los datos reales del usuario (email, nombre) se almacena por separado con acceso restringido
- El UUID en si no contiene ni permite deducir datos personales (un UUIDv4 cumple esto; un UUIDv1 basado en MAC no necesariamente)
- El proceso de re-identificacion requiere acceso a ese registro separado
Lo que un UUID NO hace:
- No cifra los datos. Un UUID que identifica a un usuario en una base de datos mal protegida sigue exponiendo los datos si se vulnera la base de datos.
- No anonimiza los datos. La pseudonimizacion bajo el RGPD sigue siendo un tratamiento de datos personales y requiere base juridica.
Practica recomendada para APIs en Espana y LATAM: Use UUIDs como identificadores publicos de recursos (el ID que aparece en la URL de la API), y mantenga los IDs internos (numericos, secuenciales) solo en la capa de base de datos. Esto evita exponer el volumen de registros y hace mas dificil la enumeracion de recursos.
UUID en APIs REST de startups espanolas y latinoamericanas
Las startups de fintech y SaaS en Espana (Madrid, Barcelona, Valencia) y en LATAM (Mexico DF, Buenos Aires, Bogota, Sao Paulo) usan UUIDs principalmente en:
- Claves primarias de tablas de usuarios, transacciones, pedidos
- Tokens de invitacion y reset de contrasena (aunque para estos casos los JWTs son mas comunes)
- Identificadores de recursos en APIs publicas:
GET /api/v1/usuarios/550e8400-e29b-41d4-a716-446655440000 - Claves de idempotencia en pagos: para que un reintento de peticion no genere un cobro duplicado
La tendencia en 2025 es migrar de UUIDv4 a UUIDv7 para las claves primarias en nuevos proyectos, especialmente en bases de datos PostgreSQL donde el soporte es nativo desde la version 17.