Are there any downsides to using nanoid for primary key?

Question

I know that UUIDs and incrementing integers are often used for primary keys. I'm thinking of nanoids instead because those are URL friendly without being guessable / brute-force scrapeable (like incrementing integers).

Would there be any reason not to use nanoids as primary keys in a database like Postgres? (For example: Maybe they drastically increase query time since they aren't ... aligned or something?)

https://github.com/ai/nanoid

Answer 1

Most databases use incrementing id's because it's more efficient to insert a new value onto the end of a B-tree based index.

If you insert a new value into a random place in the middle of a B-tree, it may have to split the B-tree nonterminal node, and that could cause the node at the next higher level to split, and so on up to the top of the B-tree.

This also has a greater risk of causing fragmentation, which means the index takes more space for the same number of values.

Read https://www.percona.com/blog/2015/04/03/illustrating-primary-key-models-in-innodb-and-their-impact-on-disk-usage/ for a great visualization about the tradeoff between using an auto-increment versus UUID in a primary key.

That blog is about MySQL, but the same issue applies to any B-tree based data structure.

Answer 2

I'm not sure if there is a disadvantage to using nanoids, but they are often unnecessary. While UUIDs are long, they can be translated to a shorter format without losing entropy.

See the NPM package (https://www.npmjs.com/package/short-uuid).