As others have said - look into securing your app in other ways.

Take this query for example: stackoverflow.com/questions/1446821/how-to-get-ne… select * from foo where id = (select min(id) from foo where id > 4)

That query technically wouldn't care if it was querying an INT or Varchar (replace the 4 with a string) - it'll pull the next record based on whats passed in. > can still apply to strings; they'll just be sorted alphabetically, not numerically.

Your goal is to stop (select min(id) from foo where id > 4) from being injected into the app. Any (all) input fields when using SQL should be sanitized.

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 😉