Should i use UUID as primary key 🚨

Should i use UUID as primary key? Short Answer:

NO! UUID is good for small projects but for larger DB UUID isn’t recommended because of storage burning and caching issues. AND UUID is for a Unique identifier not for a Primary Key. Below you can read more about why I’m saying don’t use UUID as Primary_Key.

Don’t use UUID as Primary Key 💢

some developers delete “id int primary auto-increment” and set id char(36) for UUID here are some issues you can face. I spent hours in manual testing to figure out these.

What are your thoughts if we drop primay_key “id int primary_key auto-increment”? according to my experiment never drop “int id primary auto-increment, instead make 2nd column called UUID or external_id of char data type char(36). I know its not good because of DB storage burning but think about if any primary_key is deleted suppose 5, then the new record id will be 6 and we can’t force the new id to 5 but in the case of uuid, you can use the UUID of a deleted row because UUID is not set to primary. Even if we set the UUID column as primary with auto_increment off (due to char(36) auto-increment set to off ) then still we can face the same issue. same issue with unique you can use the old UUID 2nd time if the previous record is deleted but in the case of “id int primary_key auto-increment” you can’t and we need to go with it.

UUID char(36) NOT NULL means you can save a blank value 😨, and if the column is unique then the second time we can’t save a blank value. let’s consider with a blank value, think about a foreign key. if UUID is blank then how do you use it as foreign_id, also what result you should get from last_inserted_id? probably blank.

In Case of Laravel should I use UUID as Primary Key?

if you use UUID as primary_id “id char(36)” then think about the insert() method for multiple entries will fail because we need to pass UUID manually but in the case of create(), the logic will go to Model boot to automate this process. And other things are set to auto-increment off, type string, boot method for UUID… And mistakenly you delete the id column and use a new column name UUID then manually pass the uuid column name every time in elequant relations 😑

If you use Laravel media-library package then take a look at the migration, it has both id(int primary_key) + UUID column. The UUID column is for Route Model Binding.

UUID is good for small projects but for larger DB UUID isn’t recommended because of storage burning and caching issues.

Suppose you have an EAV Database Table

And if you have an EAV database table (Entity Attribute Value), and the ID column is char(36) again the solution is manually passed UUID 😑. If you committed to passing UUID manually then it’s good to create a separate column uuid char(36) and don’t modify the default id column. Because UUID is for unique identifiers not for primary ids. and use UUID for external usage (e.g API), for query strings, URL embedded and more so, now we’ve both default id, and uuid in a table just hide the default id in APIs response, query strings, etc as we don’t want to expose ids.