I briefly read about it, it says the method is similar to just converting numbers to hex (modulo + lookup in an 'alphabet', then shift, repeat until you are at zero), but with a shuffled alphabet. That doesn't sound secure _at all_ -- if an attacker can cause you to generate a bunch of IDs very quickly, it's likely that some of them will be sequential, and from there it should be easy to figure out what the shuffled alphabet was.

Indeed, from hashids.org:

> Do you have a question or comment that involves "security" and "hashids" in the same sentence? Don't use Hashids.

and then they link to a blog post with a detailed analysis (which makes it look like their characterization as just converting a number to a shuffled alphabet doesn't capture all the details) demonstrating that it's weak.

I was going to recommend this. No reason to use a special data type for the ID in your database unless you have some sort of actual constraints (like a 64 bit limit or something).

Instead just use a sequential integer (or UUID). When you need to expose it publicly, use something like hashids ^.

The main downside to straight UUIDs as primary key, is the B-tree used to store the primary key is larger if using UUIDs which are 16 bytes vs 8 for longs. In this case though the IDs are 8 bytes so this point is moot. Also the data is stored randomly on disk, which will make things like range queries slower if querying by ID (but you probably want a different index for querying anyway).