UUIDs en SQLite: 2x más lentos y 3x más grandes que un entero

Un UUID de 128 bits almacenado como texto ocupa 36 bytes. Un entero de 64 bits, solo 8. En SQLite, esa diferencia se traduce en un 200% más de tiempo de consulta y un 300% más de espacio en disco, según benchmarks recientes.

Por qué importa

Cada milisegundo cuenta cuando tu app crece. En una tabla con 10 millones de filas, un índice sobre UUIDs ocupa ~360 MB contra ~80 MB de un entero. La fragmentación del índice B-tree por la aleatoriedad de los UUIDs ralentiza aún más las inserciones y búsquedas.

Para el desarrollador minimalista, elegir el tipo de clave correcto es una decisión de arquitectura que impacta el rendimiento y la simplicidad del sistema. No se trata solo de evitar colisiones, sino de no pagar un costo oculto por una funcionalidad que quizá no necesitas.

Qué dice el contexto

• Representación: UUID puede almacenarse como texto (36 chars), blob (16 bytes) o entero de 128 bits. En SQLite, el blob es más eficiente que texto pero sigue siendo más lento que un entero nativo.
• Índices: La aleatoriedad de UUID versión 4 provoca fragmentación en índices B-tree, aumentando el número de páginas y el tiempo de rebalanceo.
• Alternativas: SQLite permite usar INTEGER PRIMARY KEY con autoincremento, que es la opción más rápida. Para evitar colisiones en sistemas distribuidos, se recomienda usar UUIDs ordenados (tipo 1 o 7) o secuencias personalizadas.
• Compromiso: Si necesitas UUIDs por razones de seguridad o distribución, almacénalos como blob y considera usar un rowid entero como clave primaria interna, con el UUID como clave secundaria única.
• Costo real: Un estudio de Vespa muestra que las consultas con UUID como clave primaria son hasta 2.3x más lentas que con enteros, y las inserciones masivas hasta 1.8x más lentas.

Lo que puedes hacer

1. Mide antes de optimizar: Si tu app ya usa UUIDs, ejecuta un EXPLAIN QUERY PLAN y monitorea el tamaño de la base de datos. Si el rendimiento es aceptable, no cambies nada.
2. Elige UUIDs ordenados: Si estás empezando un proyecto nuevo que requiere UUIDs, usa UUID v7 (basado en timestamp) en lugar de v4. Son más amigables con los índices.
3. Separa la clave primaria del identificador público: Usa un INTEGER PRIMARY KEY interno para joins y relaciones, y un campo uuid único con índice para consultas externas. Así obtienes lo mejor de ambos mundos.

En una frase

“

En SQLite, un UUID como clave primaria duplica el tiempo de consulta y triplica el espacio en disco frente a un entero de 64 bits.