UUID vs bigint en PostgreSQL: compara tamaño de índices, orden de ordenación, preparación para sharding y cómo los IDs viajan por APIs, web y apps móviles.
Cada fila en una tabla PostgreSQL necesita una forma estable de ser encontrada otra vez. Eso hace un ID: identifica de forma única un registro, suele ser la clave primaria y se convierte en el pegamento para relaciones. Otras tablas lo almacenan como foreign key, las consultas hacen joins con él y las apps lo pasan como el identificador de “ese cliente”, “esa factura” o “ese ticket de soporte”.
Como los IDs acaban en todas partes, la elección no es solo un detalle de base de datos. Aparece después en el tamaño de índices, patrones de escritura, velocidad de consultas, tasas de acierto en caché e incluso en trabajo de producto como análisis, importaciones y depuración. También afecta qué expones en URLs y APIs, y lo fácil que es para una app móvil guardar y sincronizar datos de forma segura.
La mayoría de equipos comparan UUID vs bigint en PostgreSQL. En términos simples, estás eligiendo entre:
Ninguna opción gana en todos los casos. Bigint tiende a ser compacto y amigo de índices y ordenación. Los UUID encajan bien cuando necesitas IDs globalmente únicos entre sistemas, quieres IDs públicos menos evidentes o esperas crear datos en muchos lugares (múltiples servicios, móvil offline o sharding futuro).
Una regla práctica: decide según cómo se crearán y compartirán los datos, no solo según cómo se almacenarán hoy.
Cuando la gente compara UUID vs bigint en PostgreSQL, elige entre dos formas de nombrar filas: un número tipo contador pequeño, o un valor más largo y globalmente único.
Un bigint es un entero de 64 bits. En PostgreSQL normalmente lo generas con una columna identity (o el patrón antiguo serial). La base mantiene una secuencia internamente y entrega el siguiente número cada vez que insertas una fila. Eso significa que los IDs suelen ser 1, 2, 3, 4... y así sucesivamente. Es simple, fácil de leer y cómodo en herramientas e informes.
Un UUID (Universally Unique Identifier) tiene 128 bits. A menudo lo verás escrito como 36 caracteres con guiones, por ejemplo 550e8400-e29b-41d4-a716-446655440000. Tipos comunes incluyen:
El almacenamiento es una de las primeras diferencias prácticas: bigint usa 8 bytes, mientras que UUID usa 16 bytes. Esa diferencia aparece en los índices y puede afectar las tasas de acierto en caché (la base puede contener menos entradas de índice en memoria).
También piensa dónde aparecen los IDs fuera de la base. Los IDs bigint son cortos en URLs y fáciles de leer en logs o tickets de soporte. Los UUID son más largos y molestos de escribir, pero son más difíciles de adivinar y pueden generarse de forma segura en clientes cuando hace falta.
La diferencia práctica más grande entre bigint y UUID es el tamaño. Bigint son 8 bytes; UUID 16 bytes. Eso suena menor hasta que recuerdas que los índices repiten tus IDs muchas veces.
Tu índice de clave primaria necesita mantenerse caliente en memoria para sentirse rápido. Un índice más pequeño significa que más de él cabe en shared buffers y caché de CPU, así que búsquedas y joins requieren menos lecturas de disco. Con claves primarias UUID, el índice suele ser notablemente más grande para la misma cantidad de filas.
El multiplicador son los índices secundarios. En los índices B-tree de PostgreSQL, cada entrada de un índice secundario también almacena el valor de la clave primaria (para que la base encuentre la fila). Así que IDs más anchos inflan no solo el índice primario, sino todos los índices secundarios que añadas. Si tienes tres índices secundarios, los 8 bytes extra de los UUIDs aparecen efectivamente en cuatro sitios.
Las foreign keys y tablas de unión también lo sienten. Cualquier tabla que referencie tu ID almacena ese valor en sus propias filas e índices. Una tabla de unión muchos-a-muchos puede ser mayormente dos foreign keys más un poco de overhead, así que duplicar el ancho de la clave puede cambiar mucho su huella.
En la práctica:
Si un ID de usuario aparece en users, orders, order_items y en un audit_log, ese mismo valor se almacena e indexa en todas esas tablas. Elegir una clave más ancha es tanto una decisión de almacenamiento como de identificador.
La mayoría de claves primarias en PostgreSQL usan un índice B-tree. Un B-tree funciona mejor cuando las filas nuevas caen cerca del final del índice, porque la base puede seguir añadiendo sin reordenar mucho.
Con un bigint identity o sequence, los IDs suben con el tiempo. Las inserciones suelen golpear la parte más a la derecha del índice, así que las páginas se mantienen compactas, la caché se mantiene caliente y PostgreSQL hace menos trabajo extra.
Esto importa incluso si nunca haces ORDER BY id. La ruta de escritura aún tiene que colocar cada nueva clave en el índice en orden ordenado.
Un UUID aleatorio (común con UUIDv4) distribuye las inserciones por todo el índice. Eso aumenta la probabilidad de page splits, donde PostgreSQL debe asignar nuevas páginas de índice y mover entradas para hacer espacio. El resultado es más amplificación de escritura: más bytes de índice escritos, más WAL generado y a menudo más trabajo en segundo plano después (vacuum y gestión de bloat).
Los UUIDs ordenados por tiempo cambian la historia. Los UUIDs que aumentan mayormente con el tiempo (como estilo UUIDv7 u otros esquemas basados en tiempo) restauran gran parte de la localidad, manteniendo los 16 bytes pero con un comportamiento de inserción mucho más amigable.
Sentirás estas diferencias sobre todo cuando tengas altas tasas de inserción, tablas grandes que no caben en memoria y varios índices secundarios. Si te importan picos de latencia de escritura por page splits, evita IDs completamente aleatorios en tablas con mucho tráfico de escritura.
Ejemplo: una tabla de events ocupada que recibe logs de una app móvil todo el día suele ir más suave con claves secuenciales o UUIDs ordenados por tiempo que con UUIDs totalmente aleatorios.
La mayoría de ralentizaciones del mundo real no son “los UUIDs son lentos” o “los bigints son rápidos”. Es lo que la base de datos tiene que tocar para responder tu consulta.
Los planes de consulta se preocupan principalmente por si pueden usar un index scan para filtros, hacer joins rápidos por la clave y si la tabla está físicamente ordenada (o lo bastante cerca) para que las lecturas por rangos sean baratas. Con una clave primaria bigint, las filas nuevas se insertan en orden creciente, así que el índice primario tiende a mantenerse compacto y con localidad. Con UUIDs aleatorios, las inserciones se dispersan por el índice, lo que puede crear más page splits y un orden en disco más desordenado.
Las lecturas son donde muchos equipos lo notan primero. Llaves más grandes implican índices más grandes, e índices más grandes implican menos páginas útiles en RAM. Eso reduce las tasas de acierto en caché e incrementa IO, especialmente en pantallas con muchos joins como “lista de pedidos con info del cliente”. Si tu working set no cabe en memoria, los esquemas con muchos UUID pueden empujarte sobre ese límite antes.
Las escrituras también pueden cambiar. Las inserciones con UUID aleatorio pueden aumentar el churn en el índice, lo que presiona autovacuum y puede aparecer como picos de latencia en periodos de mucha actividad.
Si mides UUID vs bigint en PostgreSQL, hazlo honestamente: mismo esquema, mismos índices, mismo fillfactor y suficientes filas para superar la RAM (no 10k). Mide latencias p95 y IO, y prueba tanto con caché caliente como fría.
Si construyes apps en AppMaster sobre PostgreSQL, esto suele manifestarse como páginas de listado más lentas y mayor carga en la base mucho antes de que parezca un “problema de CPU”.
Si tus IDs salen de la base y aparecen en URLs, respuestas de API, tickets de soporte y pantallas móviles, la elección afecta tanto la seguridad como la usabilidad diaria.
Los IDs bigint son fáciles para humanos. Son cortos, puedes leerlos por teléfono y tu equipo de soporte puede detectar patrones rápidamente como “todos los pedidos fallidos están alrededor de 9,200,000”. Eso acelera la depuración, sobre todo si trabajas con logs o capturas de pantalla de clientes.
Los UUID ayudan cuando expones identificadores al público. Un UUID es difícil de adivinar, así que el raspado casual como probar /users/1, /users/2, /users/3 no funciona. También hace más difícil que terceros infieran cuántos registros tienes.
La trampa es pensar que “difícil de adivinar” equivale a “seguro”. Si las comprobaciones de autorización son débiles, los IDs predecibles pueden ser abusados rápido, pero los UUIDs también pueden robarse de un enlace compartido, un log filtrado o una respuesta de API cacheada. La seguridad debe venir de las comprobaciones de permisos, no de ocultar el ID.
Un enfoque práctico:
Ejemplo: un portal de clientes muestra IDs de factura. Si las facturas usan bigint y tu API solo hace “existe la factura”, alguien puede iterar números y descargar facturas de otros. Arregla la comprobación primero. Luego decide si los UUIDs para IDs públicos reducen riesgo y carga de soporte.
En plataformas como AppMaster, donde los IDs fluyen por APIs generadas y apps móviles, el valor por defecto más seguro es autorización consistente más un formato de ID que tus clientes puedan manejar de forma fiable.
El tipo que elijas no se queda en la base. Se filtra en cada frontera: URLs, payloads JSON, almacenamiento cliente, logs y analytics.
Si cambias el tipo de ID más adelante, la ruptura rara vez es “solo una migración”. Las foreign keys deben cambiar en todas partes, no solo en la tabla principal. ORMs y generadores de código pueden regenerar modelos, pero las integraciones siguen esperando el formato antiguo. Incluso un simple GET /users/123 se vuelve problemático cuando el ID pasa a ser un UUID de 36 caracteres. También tendrás que actualizar caches, colas de mensajes y cualquier lugar donde se almacenaron IDs como enteros.
Para las APIs, la decisión principal es formato y validación. Los bigints viajan como números, pero algunos sistemas (y lenguajes) corren riesgo de problemas de precisión si los parsean como punto flotante. Los UUIDs viajan como cadenas, lo cual es más seguro para parseo, pero necesitas validación estricta para evitar que “casi UUIDs” terminen en logs y bases.
En móvil, los IDs se serializan y almacenan constantemente: respuestas JSON, tablas SQLite locales y colas offline que guardan acciones hasta que vuelve la red. Los IDs numéricos son más pequeños, pero los UUIDs como strings suelen ser más fáciles de tratar como tokens opacos. Lo que causa dolor real es la inconsistencia: una capa lo guarda como entero y otra como texto, y las comparaciones o joins se vuelven frágiles.
Algunas reglas que evitan problemas:
Si construyes clientes web y móviles con un stack generado (por ejemplo, AppMaster generando backend y apps nativas), un contrato de ID estable importa aún más porque forma parte de cada modelo y petición generada.
“Preparado para sharding” suele significar que puedes crear IDs en más de un lugar sin romper la unicidad y que puedes mover datos entre nodos más tarde sin reescribir cada foreign key.
Los UUIDs son populares en setups multi-región o multi-writer porque cualquier nodo puede generar un ID único sin pedir a una secuencia central. Eso reduce coordinación y facilita aceptar escrituras en distintas regiones y fusionar datos después.
El bigint aún funciona, pero necesitas un plan. Opciones comunes incluyen asignar rangos numéricos por shard (shard 1 usa 1-1B, shard 2 usa 1B-2B), ejecutar secuencias separadas con un prefijo de shard, o usar IDs estilo Snowflake (bits de tiempo más bits de máquina o shard). Estos pueden mantener índices más pequeños que los UUID y preservar algo de orden, pero añaden reglas operativas que hay que aplicar.
Trade-offs que importan en el día a día:
Para muchos equipos, “preparado para sharding” realmente significa “preparado para migrar”. Si hoy estás en una sola base, elige el ID que facilite el trabajo actual. Si ya estás construyendo múltiples escritores (por ejemplo, mediante APIs generadas y apps móviles en AppMaster), decide temprano cómo se crean y validan los IDs entre servicios.
Empieza por describir la realidad de tu app. Una sola base PostgreSQL en una región tiene necesidades distintas a un sistema multi-tenant, un setup que luego pueda dividirse por región o una app móvil que debe crear registros offline y sincronizar después.
Luego sé honesto sobre dónde aparecerán los IDs. Si los identificadores se quedan dentro del backend (jobs, herramientas internas, paneles de administración), la simplicidad a menudo gana. Si los IDs aparecen en URLs, logs compartidos con clientes, tickets de soporte o deep links móviles, la predictibilidad y la privacidad importan más.
Usa el orden como factor decisivo, no como posdata. Si dependes de feeds “más recientes primero”, paginación estable o trails de auditoría fáciles de escanear, las IDs secuenciales (o IDs ordenados por tiempo) reducen sorpresas. Si el orden no está ligado a la clave primaria, puedes separar la elección del PK y ordenar por una marca de tiempo.
Un flujo de decisión práctico:
Ejemplo: si una app móvil crea “pedidos borrador” offline, los UUIDs permiten que el dispositivo genere IDs de forma segura antes de que el servidor los vea. En herramientas como AppMaster, eso es conveniente porque el mismo formato de ID puede fluir de la base a la API y a apps web y nativas sin casos especiales.
La mayoría de debates sobre IDs fallan porque la gente elige un tipo por una razón y luego se sorprende por los efectos secundarios.
Un error común es usar UUIDs totalmente aleatorios en una tabla con muchas escrituras y luego preguntarse por qué las inserciones son espasmódicas. Los valores aleatorios dispersan nuevas filas por el índice, lo que puede implicar más page splits y más trabajo para la base bajo carga. Si la tabla escribe mucho, piensa en la localidad de inserción antes de decidir.
Otro problema frecuente es mezclar tipos de ID entre servicios y clientes. Por ejemplo, un servicio usa bigint y otro usa UUID, y tu API acaba con IDs numéricos y cadenas. Eso suele derivar en bugs sutiles: JSON parsers que pierden precisión en números grandes, código móvil que trata IDs como números en una pantalla y como strings en otra, o claves de cache que no coinciden.
Una tercera trampa es tratar “IDs difíciles de adivinar” como control de acceso. Incluso con UUIDs, necesitas checks de autorización correctos.
Finalmente, los equipos cambian el tipo de ID tarde sin plan. La parte más dura no es la PK en sí, son todas las cosas ligadas a ella: foreign keys, tablas de unión, URLs, eventos de analytics, deep links móviles y estado almacenado en clientes.
Para evitar dolor:
Si construyes con una plataforma generadora de código como AppMaster, la consistencia importa aún más porque el mismo tipo de ID fluye del esquema de la DB al backend generado y a web y apps móviles.
Si estás atascado, no empieces por la teoría. Empieza por cómo será tu producto en un año y en cuántos sitios viajará ese ID.
Pregúntate:
Después de responder, revisa la infraestructura. Si usas bigint, asegúrate de tener un plan claro para la generación de IDs en cada entorno (especialmente dev local e importaciones). Si usas UUID, asegúrate de que los contratos de API y modelos cliente manejen IDs como cadenas consistentemente y que el equipo pueda leerlos y compararlos.
Una prueba rápida: si una app móvil necesita crear un pedido offline y luego sincronizar, los UUIDs suelen reducir trabajo de coordinación. Si tu app es mayormente online y quieres índices compactos, bigint suele ser más sencillo.
Si construyes apps en AppMaster, decide temprano porque la convención de IDs fluye por tu modelo PostgreSQL, APIs generadas y apps web y nativas.
Una empresa pequeña tiene una herramienta interna de operaciones, un portal de clientes y una app móvil para personal de campo. Los tres consumen la misma base PostgreSQL a través de una API. Se crean registros todo el día: tickets, fotos, actualizaciones de estado y facturas.
Con bigint los payloads de la API son compactos y fáciles de leer:
{ "ticket_id": 4821931, "customer_id": 91244 }
La paginación se siente natural: ?after_id=4821931&limit=50. Ordenar por id suele coincidir con el tiempo de creación, así que “últimos tickets” es rápido y predecible. La depuración es simple: soporte puede pedir “ticket 4821931” y la mayoría puede escribirlo sin errores.
Con UUIDs, los payloads son más largos:
{ "ticket_id": "3f9b3c0a-7b9c-4bf0-9f9b-2a1b3c5d1d2e" }
Si usas UUID v4 aleatorio, las inserciones caen por todo el índice. Eso puede significar más churn de índices y depuración más basada en copiar/pegar. La paginación suele pasar a tokens tipo cursor en lugar de “after id”.
Si usas UUIDs ordenados por tiempo, mantienes la mayor parte del comportamiento “más recientes primero” mientras evitas IDs adivinables en URLs públicas.
En la práctica, los equipos suelen notar cuatro cosas:
La mayoría de equipos se atascan buscando la respuesta perfecta. No necesitas perfecta. Necesitas un valor por defecto que encaje hoy y una forma rápida de demostrar que no te hará daño después.
Reglas que puedes estandarizar:
Antes de fijarlo, haz un pequeño experimento. Crea una tabla con tamaño de fila realista, inserta 1 a 5 millones de filas y compara (1) tamaño de índices, (2) tiempo de inserción y (3) unas consultas comunes con la PK y un par de índices secundarios. Hazlo en tu hardware real y con la forma real de tus datos.
Si te preocupa cambiar después, planifica una migración aburrida:
Si construyes en AppMaster (appmaster.io), vale la pena decidir temprano porque la convención de IDs fluye por tu modelo PostgreSQL, APIs generadas y apps tanto web como nativas. El tipo específico importa, pero la consistencia suele importar más cuando tienes usuarios reales y varios clientes.
¿Debo usar bigint o UUID como clave primaria en PostgreSQL?Por defecto usa bigint cuando tienes una sola base PostgreSQL, la mayoría de escrituras ocurren en el servidor y te importan índices compactos y un comportamiento de inserción predecible. Elige UUIDs cuando los IDs deban generarse en muchos sitios (múltiples servicios, móvil offline, shardings futuros) o cuando no quieras que los IDs públicos sean fáciles de adivinar.
¿Por qué los UUIDs hacen que los índices y el almacenamiento crezcan tanto?Porque el ID se copia en muchos sitios: el índice de la clave primaria, cada índice secundario (como puntero a la fila), columnas de foreign key en otras tablas y tablas de unión. Los UUID ocupan 16 bytes frente a 8 bytes de un bigint, así que la diferencia de tamaño se multiplica a lo largo del esquema y puede reducir las tasas de acierto en caché.
¿Los UUIDs ralentizan las inserciones comparados con bigint?En tablas con muchas inserciones, sí. Los UUIDs aleatorios (como v4) dispersan las inserciones por todo el B-tree, lo que aumenta los page splits y la rotación del índice bajo carga. Si quieres UUIDs pero también inserciones suaves, usa una estrategia de UUID ordenada por tiempo para que las claves nuevas vayan mayormente al final.
¿Notaré lecturas más lentas con UUIDs?Suele manifestarse como más IO, no tanto como CPU más lenta. Llaves más grandes implican índices más grandes, y índices más grandes significan que menos páginas entran en memoria, por lo que joins y búsquedas pueden provocar más lecturas. La diferencia se nota sobre todo en tablas grandes, consultas con muchos joins y sistemas cuyo conjunto de trabajo no cabe en RAM.
¿Los UUIDs son más seguros que los bigint en APIs públicas?Los UUIDs ayudan a reducir adivinanzas fáciles como /users/1, pero no reemplazan la autorización. Si tus checks de permisos fallan, los UUIDs pueden filtrarse y volver a usarse. Trata los UUIDs como una comodidad para identificadores públicos y confía en controles de acceso estrictos para seguridad real.
¿Cuál es la mejor forma de representar IDs en APIs JSON?Usa una representación canónica y cúmplela. Un valor práctico por defecto es tratar los IDs como cadenas en las solicitudes y respuestas de la API, incluso si la base usa bigint, porque evita problemas numéricos en clientes y simplifica la validación. Sea lo que sea, mantenlo consistente en web, móvil, logs y caches.
¿Los bigints causan problemas en JavaScript o apps móviles?Los bigints pueden fallar en algunos clientes si se parsean como punto flotante, lo que provoca pérdida de precisión en valores grandes. Los UUIDs lo evitan porque son cadenas, pero son más largos y se manejan mal si no se valida estrictamente. Lo más seguro es la consistencia: un tipo en todas partes, con validación clara en el borde de la API.
¿Qué debería escoger si podría shardear o estar en varias regiones luego?Los UUIDs son una opción clara porque se pueden crear independientemente sin coordinar una secuencia central. Los bigint también valen, pero necesitas reglas como rangos por shard o un generador tipo Snowflake, y debes aplicarlas siempre. Si quieres la historia distribuida más simple, elige UUIDs (preferiblemente ordenados por tiempo).
¿Qué tan doloroso es migrar de bigint a UUID (o al revés)?Cambiar el tipo de clave primaria impacta mucho más que una columna. Debes actualizar foreign keys, tablas de unión, contratos de API, almacenamiento en clientes, caches, eventos de analytics y cualquier integración que guardara IDs como números o cadenas. Si puedes necesitar el cambio, planifica una migración gradual con dual-write y una ventana de transición larga.
¿Puedo usar ambos: bigint internamente y UUID externamente?Mantén una clave interna bigint para eficiencia y añade un UUID público (o token) separado para URLs y APIs externas. Así tienes índices compactos y depuración interna simple mientras evitas enumeración fácil en identificadores públicos. La clave es decidir pronto cuál es el “ID público” y no mezclarlos a la ligera.
27 ene 2026
8 min
26 ene 20268 min
21 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
