You can also just go ahead and use an auto-incrementing PK but have an "external" representation for it that is not stored. One strategy (which incurs a little

You can also just go ahead and use an auto-incrementing PK but have an "external" representation for it that is not stored. One strategy (which incurs a little bloat on the wire) is to encrypt the value on the way in and out. You also have the option of incorporating per-session, per-user or per-group information into a computed ID obfuscating key so that IDs are not "shareable" across certain boundaries. Do use a "key per table" (or "mix" the table name into a computed key) or else encrypted IDs for different types of entity will be the same (e.g. ID 1 from table A will map to the same value as ID 1 from table B). ECB mode for this stuff is usually fine unless you are filling up a really big part of the key space. You probably do want an integrity mode if you are planning to use something like this to "pre-compute" access control checks (e.g. skip access control on an item lookup because that was done during item listing). Generally do not recommend skipping access control + visibility checks without a compelling reason even if your IDs are in theory unguessable / unforgeable. The rub is key rotation, and how much you care about it. If your IDs tend to end up being stored permanently external to your system (e.g. it's a blog post ID or something) then a stored random ID is probably better. For IDs which are not primary entry points to your application then the keyed approach can offer good flexibility, performance and storage characteristics.