Todo el mundo te da el mismo consejo sobre las primary keys: o "usa autoincrement" o "usa UUID". Y la verdad es que los dos, así sueltos, se quedan cortos. El ID secuencial de toda la vida, el bigint, es rapidísimo, ocupa poco y a la base le encanta. Su punto débil no es cómo funciona, es enseñarlo: el día que ese número aparece en la URL, tipo /pedido/1042, le estás contando al mundo cuántos pedidos llevas, y cualquiera se pone a probar 1041, 1043, a ver qué encuentra. Por eso mucha gente salta al UUID aleatorio, el v4. Resuelve lo de arriba, nadie adivina esos IDs, pero le muda el problema a la base: como el valor es aleatorio, cada fila nueva cae en un lugar distinto del índice, el B-tree se fragmenta, y con millones de registros se nota en escrituras y en tamaño. La salida elegante, de la que casi nadie habla, es el UUIDv7. La clave está en su estructura: los primeros dígitos son la marca de tiempo de cuándo se creó, y el resto sí es aleatorio. Como el tiempo va al frente, los IDs nacen ya en orden y el índice se mantiene sano como con un secuencial; y como el resto es aleatorio, por fuera sigue siendo imposible de adivinar. Ese es el truco. Postgres 18 ya lo trae nativo, y como Supabase por dentro es Postgres, lo tienes ahí mismo. Al final el debate no es bigint contra UUID. Es entender que el ID que guardas y el ID que muestras no tienen por qué ser el mismo. Para adentro, lo que sea más rápido. Para lo que sale al mundo, algo que no se pueda adivinar.

Perder la base de datos de un cliente es de las pocas cosas que te sacan del negocio de un día para otro. Un backup automático cifrado cuesta cuatro líneas y corre solo cada noche. Postgres: pg_dump -Fc midb | age -r TU_CLAVE > /backups/midb-$(date +%F).age MySQL / MariaDB: mysqldump --single-transaction midb | age -r TU_CLAVE > /backups/midb-$(date +%F).age Lo subes fuera del server y rotas: rclone copy /backups r2:midb-backups find /backups -mtime +14 -delete Al cron a las 3am: 0 3 * * * /ruta/backup.sh Restore, el día que toque: Postgres: age -d -i TU_LLAVE midb-2026-08-25.age | pg_restore -d midb MySQL/MariaDB: age -d -i TU_LLAVE midb-2026-08-25.age | mysql midb Tres cosas que casi todos se saltan: 1. Cifrar antes de subir (age o gpg). No confíes en que el bucket es privado. 2. Rotar y borrar los viejos, o el almacenamiento crece sin freno y sin que te enteres. 3. Probar el restore una vez al mes. Un backup que nunca restauraste no es un backup, es fe. Barato, silencioso, y el día que un disco muera vas a dormir igual.