Post

bigint for primary keys, slugs or NanoIDs when exposing IDs publicly 🔥 From my testing bigint performs better than UUIDs especially when joining multiple tables Also not a fan of UUIDs as public IDs or in logs, prefer NanoIDs, mainly cos of length, easy to select & IMO looks nicer #buildinpublic

Anant Parmar@anantparmar.com

ULID, UUID, bigInt, int What's your go to primary key type? #buildinpublic

14/12/24, 6:52 am1 repost5 likes

David

@drodol.com

14 Dec 2024

Didn't know about NanoIDs

Navin Peiris

@navinpeiris.com

14 Dec 2024

Oldie, but a goldie, on why PlanetScale chose NanoIDs for their APIs: planetscale.com/blog/why-we-...

planetscale.comWhy we chose NanoIDs for PlanetScale’s API — PlanetScaleLearn why PlanetScale used NanoID to generate obscure and URL friendly identifiers.

Jace Warren

@jacewarren.bsky.social

15 Dec 2024

Whoa! Had no idea. Thanks for the share

Mark Snape

@snapey.bsky.social

14 Dec 2024

I prefer bigint for primary keys and a seperate hashid for the public facing record reference. For new projects I'll probably choose sqids. sqids.org

sqids.orgSqids (formerly Hashids) · Generate Short Unique IDsSqids is a lightweight, customizable library that converts numbers into short, URL-safe IDs. It's a flexible and collision-free solution for generating unique IDs.

Navin Peiris

@navinpeiris.com

14 Dec 2024

I had no clue they renamed hashid to sqids! Yes, love hashids for when you want to obscure one or more int ids, but I’ve started preferring nanoids for when you want to store that id in the DB at insertion time