GUID or Varchar(36)?
2 min read
While working on an application which had a foreign key GUID reference, we had to change the implementation for that field to accept a string. Then we came across the question as to whether GUIDs or a Varchar(36) field would perform better?
First off, what is a GUID?
In essence a GUID is an integer value. Of course, it is a 128 bit integer value taking 16 bytes to store. What we usually see (b6aa92e9-5ae9-47f4-ad2f-ebc36452c61d) is the human readable hexadecimal string. But GUID values are not stored or processed as strings. The other difference to a 128-bit integer is how the next GUID is generated – randomly, rather than sequentially.
See comments in this article for more info:
Why compare against Varchar(36)?
That's because the hexadecimal representation of a GUID is 36 characters long. So if you are storing the GUID as a string, you need a Varchar(36) field.
See this article on the pros and cons:
So what performs better?
Having said that a GUID takes 16 bytes and Varchar(36) takes 36 bytes, the GUID will always outperform it's counterpart. Other than that, it would be somewhat faster to compare GUID values because it's a simple numeric comparison and doesn't have to consider lexical rules.
If it is either a GUID or Varchar(36) field, make sure that it is indexed to have a performance gain. Also consider your requirements to make sure what suits you best.
This article was originally written on Google's Blogger platform and ported to Hashnode on 17 Sep 2022.