Toolram
Generadores

Qué es un UUID y cuándo usarlo (v4 vs v7 explicado, 2026)

UUIDs son identificadores únicos universales de 128 bits. Esta nota explica para qué sirven, las versiones (v1, v4, v7), y cuándo usar UUID vs auto-increment integer.

Por José Gaspard·27 de mayo de 2026· 5 min

La idea

UUID = Universally Unique Identifier. Es un identificador de 128 bits expresado como 32 caracteres hex en 5 grupos: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Ejemplo: 550e8400-e29b-41d4-a716-446655440000

Por qué importan

El problema que resuelven: generar IDs únicos sin coordinación central.

Si tu app tiene 10 servidores creando registros concurrentemente, no podés usar AUTO_INCREMENT (cada server tendría que pedir el siguiente número al DB → bottleneck). Con UUIDs, cualquier server (o cliente) puede generar uno y la probabilidad de colisión es prácticamente cero (1 en 5.3 × 10^36 para v4).

Las versiones más usadas

UUID v1 — timestamp + MAC

Basado en el momento de generación + dirección MAC de la máquina.

  • ✅ Ordenable por tiempo
  • ❌ Expone MAC address (privacy leak)
  • ❌ Casi nadie lo usa hoy

UUID v4 — completamente random

122 bits aleatorios (los otros 6 son version + variant).

  • ✅ Sin info filtrada
  • ✅ El estándar de facto desde 2010
  • ❌ No es ordenable por tiempo → mal para índices DB

UUID v7 — time-orderable (2024)

Combina timestamp (48 bits) + random (74 bits).

  • ✅ Random pero ordenable por tiempo de creación
  • ✅ Mucho mejor performance en índices DB (B-tree)
  • ✅ Nuevo estándar recomendado para DBs

Cuándo usar UUID vs auto-increment

Usá UUID cuando:

  • Tenés sistema distribuido sin DB central única
  • Los IDs son visibles públicamente (URLs, APIs) — UUIDs no revelan cuántos registros tenés
  • Necesitás generar IDs offline (mobile app sin conexión)
  • Querés migrar/mergear bases de datos sin colisiones

Usá auto-increment cuando:

  • Tu DB es monolítica
  • Performance de inserts es crítico (auto-increment es 4 bytes vs 16 de UUID)
  • Los IDs son internos (no expuestos)
  • No te importa exponer "cuántos registros hay"

¿UUID en URLs es buena idea?

Tres consideraciones:

  1. Privacy: /post/1234 → todos saben que tenés ~1234 posts. /post/550e... → no exponés nada.
  2. SEO: Google indexa ambos igual. Pero URLs con slugs descriptivos (/post/como-hacer-x) son mejores para SEO que cualquier ID numérico o UUID.
  3. UX: URLs con slugs son compartibles. UUIDs largos rompen UX.

Recomendación: UUID en API + slug en URL pública. Ej: /post/{slug} y /api/posts/{uuid}.

Próximos pasos

Preguntas frecuentes

¿Hay riesgo de que dos UUIDs v4 sean iguales?

Casi cero. La probabilidad de colisión entre dos UUIDs v4 aleatorios es ~1 en 5.3 × 10^36. Para tener 50% de chance de UNA colisión necesitarías generar ~2.71 quintillones de UUIDs. En la práctica, considerá imposible.

¿UUID v7 es mejor que v4 para todo?

Para almacenamiento en bases de datos con índices: sí. v7 es ordenable por timestamp → inserts secuenciales en B-tree → mucho mejor performance que v4 (que distribuye random y fragmenta el índice). Para casos donde NO querés revelar el momento de creación, v4 sigue siendo mejor.

¿Por qué UUID son 36 caracteres si son 128 bits?

128 bits = 16 bytes = 32 caracteres hex. Los 4 caracteres extra son los guiones que separan los grupos (8-4-4-4-12). El formato con guiones está en el RFC 4122 — es el estándar visual aunque internamente son solo 16 bytes.

Qué es un UUID y cuándo usarlo (v4 vs v7 explicado, 2026) | Toolram