PostgreSQL 19 Pulirá las UUIDv7: Timestamps Extraíbles y Formato base32hex

La versión 19 está en la recta final

PostgreSQL 19 ya está en beta 4 y entrando en la fase de release candidates — la GA debería llegar en las próximas semanas si el calendario habitual se cumple. Entre REPACK, autovacuum paralelo y mejoras del planner hay un detalle que nos toca de cerca: el soporte de UUIDs se refuerza con casts directos uuid↔bytea y, lo más interesante, codificación base32hex.

Desde PostgreSQL 18 la base de datos ya generaba UUIDv7 de forma nativa con uuidv7(). La 19 completa el puzzle.

---

Repaso rápido: por qué UUIDv7 importa

Una UUIDv4 es 122 bits de azar puro: perfecta para unicidad, terrible para índices. Cuando insertas miles de filas con primary keys v4, cada una aterriza en una posición aleatoria del árbol B-tree — page splits, cache frío, índices que crecen sin sentido.

La UUIDv7 (definida en RFC 9562) pone 48 bits de timestamp Unix en milisegundos al principio y rellena el resto con azar. Resultado: IDs únicos que además se ordenan cronológicamente. Los inserts van siempre al final del índice, como con un serial, pero sin la colisión entre instancias.

SELECT uuidv7();
-- 019535d9-3df7-79fb-b466-fa907fa17f9e
--  └──────┘ └──────────────┐
--  timestamp ms            versión (7) + aleatorio

---

Lo nuevo en la 19

Extraer el timestamp de una UUID

uuid_extract_timestamp() te devuelve el instante exacto en que se generó una UUID v1 o v7:

SELECT uuid_extract_timestamp('019535d9-3df7-79fb-b466-fa907fa17f9e'::uuid);
-- 2025-02-23 21:46:24.503-05

Para auditoría, particionado o simplemente depuración, esto es oro: el ID ya lleva su propia fecha de creación embebida. Y sí, ese timestamp se puede traducir directamente con nuestro conversor de timestamps.

base32hex: la UUID más corta que sigue ordenándose

La novedad estrella de la 19: encode()/decode() ahora aceptan base32hex. Una UUIDv7 codificada en base32hex ocupa 26 caracteres en lugar de 36 — y, crucialmente, se ordena igual que el binario con collation C. Puedes exponer IDs compactas en URLs sin perder el orden cronológico:

SELECT rtrim(encode(uuidv7()::bytea, 'base32hex'), '=');
-- 06G17TVDU1R0R9IKUBM6MEKN14   (24-26 chars, ordenable, sin guiones)

---

¿Migro mis IDs a v7?

• Tablas nuevas con mucho insert: sí, sin dudarlo. DEFAULT uuidv7() en la columna y listo.
• IDs expuestos en URLs/APIs: considera base32hex para acortar.
• Datos sensibles: ojo — una v7 filtra cuándo se creó el registro. Si eso importa, quédate en v4.
• Ordenación por ID = ordenación temporal: recuerda que el timestamp es del generador; si lo genera la app y no la BD, relojes desincronizados pueden ordenar mal unos milisegundos. Raramente importa, pero conviene saberlo.

Si quieres ver la anatomía de cada versión de UUID — dónde van los bits de versión, variante y timestamp — genera unas cuantas con nuestro generador de UUIDs y compáralas.

La discusión "serial vs UUID" llevaba años en tablas: PostgreSQL 19 la está cerrando del todo.