Database ID Strategies

Database IDs should be considered an implementation detail. It's better to assign a randomly-generated identifier for public-facing APIs for exactly this reason.

My preference: using traditional incremental numeric IDs and obfuscate them with Hashids (https://hashids.org) when exposed publicly

Question: why not use UUIDv7 but encrypt the user-facing ID you hand out? Then it's just a quick decrypt-on-lookup, and you have the added bonus of e.g. being able to give different users different IDs

That sounds really overkill for simply wanting an identifier that doesn't change, isn't guessable, and doesn't reveal how many rows there are

What's wrong with integer IDs?

Noob question, but why no use ints for PK, and UUIDs for a public_id field?

I assume you mean internal IDs == primary keys in your database. If that's the case, and if your primary keys are UUIDv4's, ULIDs, KSUIDs, Cuids or similar... then why not? There are a lot of benefits, such as simpler SQL queries in your backend. You can also merge data from different databases into one as collissions are highly unlikely, which is not possible with numeric IDs.

It's a security vs convenience tradeoff. For most people, making the ID practically unguessable, while also preserving index locality in databases, is the right balance.

One of the best pieces of programming advice I got at Google was consider IDs carefully. This is not a solved problem, and there isn't a one-sized-fits-all solution. Rather, there are a bunch of guide rules, and then you need to understand your problem domain very well to choose good identifiers.An ID should be:1.) Actually an identifier, i.e. it needs to identify objects uniquely and must be immutable throughout the lifetime of the object.2.) Assigned at object-cre

Don't expose primary keys to the public. Create separate external ids instead. I personally use BIGINT primary keys, with UUIDv4 external ids, but any random string will do.