Generador de UUID v7

Durante años, los equipos de ingeniería que querían la resistencia a colisiones de un UUID pero el ordenamiento amigable con índices de un entero secuencial tuvieron que construir su propio híbrido no estándar — comúnmente anteponiendo un UUID aleatorio con un timestamp generado manualmente, un enfoque usado en varias formas por varias empresas de sistemas distribuidos conocidas antes de que existiera ningún estándar oficial para ello. RFC 9562 formalizó ese patrón en una versión oficial de UUID específicamente para que implementaciones a través de distintos lenguajes y bases de datos pudieran producir y reconocer la misma estructura ordenada por tiempo sin que cada equipo reinventara independientemente una variante ligeramente distinta e incompatible de la misma idea.

Los 48 bits iniciales de un UUID v7 codifican un timestamp Unix en milisegundos, que es lo que le da al valor su orden de clasificación — comparar dos UUID v7 como cadenas planas refleja correctamente cuál se generó primero, ya que la porción de timestamp domina la comparación. Los bits restantes permanecen llenos de datos criptográficamente aleatorios, exactamente como en v4, así que el valor es igual de resistente a ser adivinado que lo sería un UUID completamente aleatorio; solo cambia su comportamiento de ordenamiento, no su impredecibilidad.

Más allá de la velocidad de inserción cruda, una clave primaria ordenada por tiempo tiene un segundo beneficio práctico que importa día a día: las filas vuelven naturalmente en orden de creación desde una simple consulta `ORDER BY id`, sin necesitar una columna `created_at` separada y un índice adicional en ella solo para ordenar registros cronológicamente. Para una tabla que se consulta frecuentemente "más reciente primero" — un registro de actividad, una cola, un rastro de auditoría — una clave primaria v7 da ese ordenamiento gratis como efecto secundario del propio ID, en lugar de como un coste separado que mantener.