Qué es un UUID y cuándo usarlo en tus proyectos de desarrollo
Si has trabajado con bases de datos o APIs, probablemente te has topado con identificadores como "550e8400-e29b-41d4-a716-446655440000" en vez de simples números 1, 2, 3. Esta guía explica qué son los UUID, por qué existen, y cuándo tiene sentido usarlos en vez de un ID incremental tradicional.
Qué es un UUID exactamente
UUID significa Universally Unique Identifier — un identificador de 128 bits representado como 32 caracteres hexadecimales, agrupados en el formato estándar 8-4-4-4-12 (ej: 550e8400-e29b-41d4-a716-446655440000). Está definido en el estándar RFC 4122, que especifica varias "versiones" según cómo se genera el valor.
La versión más común hoy es la 4 (UUID v4), donde prácticamente todos los bits son generados aleatoriamente. Otras versiones (1, 3, 5, 7) usan combinaciones de timestamp, direcciones de red, o hashes de nombres — cada una con propósitos distintos, pero v4 es el estándar de facto cuando solo necesitas "un identificador único, ya".
Por qué no simplemente usar 1, 2, 3...
Un ID incremental (autoincrement) tiene una limitación estructural: requiere coordinación central. Solo una base de datos puede decidir "el siguiente número es el 47" sin arriesgar duplicados. Esto funciona perfectamente en un sistema con una sola base de datos, pero se vuelve un problema en sistemas distribuidos — microservicios, aplicaciones offline-first, sincronización entre dispositivos — donde múltiples fuentes necesitan generar IDs de forma independiente sin comunicarse entre sí.
Los UUID resuelven esto por diseño: cualquier sistema, en cualquier lugar, sin coordinación con nadie más, puede generar un UUID con una probabilidad de colisión tan baja que es estadísticamente irrelevante (1 en 5.3×10³⁶ para UUID v4). Además, un ID incremental revela información (cuántos registros existen, en qué orden se crearon), mientras que un UUID no filtra esa información.
Desventajas a tener en cuenta
Los UUID no son gratis: ocupan más espacio de almacenamiento (16 bytes vs 4-8 de un entero), y como clave primaria en algunas bases de datos relacionales pueden degradar el rendimiento de índices B-tree porque los valores no son secuenciales (esto se mitiga con UUID v7, que incluye un timestamp ordenable al inicio). Tampoco son fáciles de leer o comunicar verbalmente comparados con "el pedido #47".
La decisión práctica: usa UUID cuando necesites generación descentralizada, IDs no adivinables (seguridad por ofuscación adicional), o vayas a fusionar datos de múltiples fuentes. Usa IDs incrementales cuando tengas una sola fuente de verdad y el rendimiento de índices secuenciales importe más que la descentralización.
Preguntas frecuentes
- ¿Todos los UUID son igual de aleatorios?
- No — solo la versión 4 es mayormente aleatoria. Otras versiones incorporan timestamps o hashes con propósitos específicos de ordenamiento o determinismo.
- ¿Puedo usar UUID como clave primaria en cualquier base de datos?
- Sí, técnicamente, pero en bases de datos relacionales con índices B-tree puede afectar el rendimiento de inserciones a gran escala. UUID v7 (ordenable por tiempo) mitiga este problema.
- ¿Un UUID puede repetirse?
- La probabilidad es tan baja que se considera prácticamente imposible en cualquier aplicación real — necesitarías generar miles de millones por segundo durante décadas para tener una probabilidad significativa de colisión.
- ¿Cómo genero un UUID en JavaScript?
- Con crypto.randomUUID(), disponible de forma nativa en todos los navegadores modernos y en Node.js, sin necesidad de librerías externas.