Comment by Hippo on "Which one is better for primary key - INT or Varchar?"

Like @lorthirk said, you should probably work on securing your APIs in other ways. But if you decide to go with UUIDs then, I'm not that experienced with databases, but here's what I can gather from some quick googling:

UUID storage (at least in some database engines) is less efficient than autoincrement, because those engines store the data in sequential order according to primary key. So, since UUIDs are not sequential but random, the records (or indexes?) will have to be inserted in the correct place in sequential order which can take a lot of effort if you have multiple records.
This is okay for small data sets, but once you get to millions this indexing is going to impact your performance. If your data set isn't going to get very large then, depending on the situation, UUIDs might still be a good option.
If you do use decide to use UUIDs, use varbinary instead of varchar. varbinary is more efficient because it stores the data internally as a number and therefore also uses up less space. (One such setup is described in this blog post).

By the way, all the above applies only to relational databases (and perhaps not to all of them?). It's mainly because the databases weren't designed with UUIDs in mind. Some of the newer databases like MongoDB use UUID primary-keys by default. Not to say that you must use them or anything, but it's good to keep that in mind 😉

Search Hashnode