Sequential IDs are faster. UUIDs are safer.
I wanted both speed and security, so I picked both.
Discussion
Loading...
Postgres' bigserial is compact, fast, and plenty large. But it leaks row counts and makes your API vulnerable to ID enumeration.
UUIDs solve that, but they’re bulky, slow to index, and annoying to select or copy.
So I split responsibilities:
- privateId: a sequential bigserial, used only for db internal references
- id: a prefixed Nano ID like us_msny03yjrocv, used everywhere else
The prefix (e.g. us_, ag_, dn_) reveals the entity type. The rest is short, unambiguous, and random.
This setup delivers the best of both worlds:
- Fast joins and cache-friendly indexes
- Opaque, secure public IDs with great DX
No need to compromise.
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled