First, if you can model your data using a natural key (singular or composite), and it doesn't unduly bloat the key, do so. This isn't always possible, of course (you wouldn't want to use an email address as a PK, as tempting as it may seem, since they're subject to change by users), but in many cases it is. Even better, for pre-existing data that's unlikely to change, like SKUs, you could pre-sort the data so you avoid any random page costs.
Barring that, design your API in such a way that you can use an incrementing integer without fear of leaking anything. At the very least, you can create an association table that maps an external ID (preferably UUIDv7 or ULID, as they're k-sortable) to the internal integer ID.
If you can't do either, use UUIDv7 or ULID. I prefer UUIDv7, especially since Postgres will be natively supporting their generation in an upcoming release (and because you can store them in RDBMS' native binary format), but either will do.
As to alternatives:
First, if you can model your data using a natural key (singular or composite), and it doesn't unduly bloat the key, do so. This isn't always possible, of course (you wouldn't want to use an email address as a PK, as tempting as it may seem, since they're subject to change by users), but in many cases it is. Even better, for pre-existing data that's unlikely to change, like SKUs, you could pre-sort the data so you avoid any random page costs.
Barring that, design your API in such a way that you can use an incrementing integer without fear of leaking anything. At the very least, you can create an association table that maps an external ID (preferably UUIDv7 or ULID, as they're k-sortable) to the internal integer ID.
If you can't do either, use UUIDv7 or ULID. I prefer UUIDv7, especially since Postgres will be natively supporting their generation in an upcoming release (and because you can store them in RDBMS' native binary format), but either will do.
[0]: https://news.ycombinator.com/item?id=39254871#39260773