Its easy to create plausible scenarios where things have UUID IDs. For example, your classic customer database. Each customer has an ID. Its hard to find a n

Its easy to create plausible scenarios where things have UUID IDs. For example, your classic customer database. Each customer has an ID. Its hard to find a natural key for something as simple as a customer... If you have a very narrow customer base then perhaps the company has a VAT number or something that seems natural. But get an international customer, or simply have problems getting people to enter those kind of details, gets unworkable fast. And then I suppose the 'trading name' is another natural identifier, except they can change. Hell, we've all experienced systems that have used the email address as a natural key, and all the resulting pain as those change. Just today, in fact, I had trouble with a jetbrains subscription when I used my company's new domain name to register something and it created a new account for me. Ugh. Can't work out how to link them, just because I changed the email address on the pay page instead of the account page. Jetbrains, we expect better of you! So, anyway, its normal to go with an auto-increment. But, then, the modern web site you've just built exposes that id to the customer, and you've just leaked how many customers you have! So modern best practice is to only expose UUIDs in public APIs. And I'm saying, go with ULIDs instead. Your database will thank you.