GUID or Varchar(36)?

GUID or Varchar(36)?

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.