Al diseñar una API con Postgres o MySQL, la pregunta "¿clave autoincremental o UUID?" llega antes o después. Esta es la comparación real con la que decidimos en Toolbrik.
UUID v4 (aleatorio)
- Ventajas: no revela volumen de negocio ni orden; se genera en el cliente sin round-trip; imposible de adivinar por fuerza bruta (122 bits de entropía).
- Inconvenientes: índices con páginas dispersas en b-trees (menos densidad de caché); 36 caracteres de texto.
UUID v1 (basado en tiempo)
- Ventajas: orden temporal aproximado, útil para "event sourcing" o particionado por fecha.
- Inconvenientes: revela la fecha y (según implementación) el nodo que lo generó. Vulnerable a adivinación si usas un nodo fijo.
IDs secuenciales
- Ventajas: índices compactos y rápidos, fácil debugging, URLs limpias (
/users/42). - Inconvenientes: enumerables — cualquiera puede barrer tu recurso; requieren el servidor para generarse; un bug de concurrencia los puede clonar.
Recomendación práctica
- Usa UUID v4 como clave primaria por defecto.
- Genera los UUID en el servidor si quieres ocultar orden, o en el cliente si buscas latencia cero.
- Para tablas de eventos, valoras v1; para catálogos internos, una secuencia está dentro de lo razonable.
- SIEMPRE guarda el UUID como
uuiden la base de datos, no comovarchar, y úsalo como claves de caché.
Normalizar UUIDs de origen dudoso
No todos los sistemas emiten UUIDs con el mismo formato: te vas a encontrar mayúsculas, el prefijo urn:uuid: de algunos estándares (WSDL, ATOM), o cadenas de 32 caracteres sin guiones. El validador de UUID acepta las tres variantes, detecta la versión y la variante (RFC 4122 vs. reservada), y lo convierte al formato canónico en minúsculas antes de que lo guardes.
Puedes generar cuantos necesites con nuestro generador de UUID (v4 y v1, con o sin guiones) y validar cualquier lista con el validador antes de commitearla.