Curious... I've been wracking my brain to learn the reason for this. Why use a blob as PK and FK to other tables in the database, especially a simple relational database like 'desolationredux'? Blobs are not great for building indices, nor are they great for performance in general. They also complicate joins and other database management activities. Is this a security feature, or perhaps there is some other reason? If so, can someone send a link? As stated at the beginning... Curious. Food for thought and one of the many references that advise against using blobs as primary keys: https://stackoverflow.com/questions...if-i-use-a-blob-field-as-primary-key-in-sqlit Why you shouldn't use it A primary key is often indexed and used for sorting. A BLOB cannot be indexed which makes it the slowest of all datatypes. In fact, it is the worst choice as primary key and most databases, including the SQL99 standard, disallow it. The problem with a BLOB is that its datatype is not known by the database (a BLOB should only be used for anything undefined, like an logo, an image, a word document, that can only be stored as binary data). Hence it cannot optimize it. Another problem is display. A blob cannot simply be displayed as text. Most SQL implementations do not allow BLOB fields compared, but SQLite allows it. However, it converts anything your compare it to into a blob and then compares it bit by bit. Best alternative The best option for a primary key column in SQLite is to use the INTEGER PRIMARY KEY as described here;: http://www.sqlite.org/lang_createtable.html#rowid it gives the best performance (it is already there as the rowid column, it is just aliased). Conclusion To answer your question: yes, it influences the performance badly. But more importantly, it will make it very hard to manage your tables well. Use INTEGER PRIMARY KEY, it is really the best, guaranteed unique and is blazingly fast. More PK references / reading material: http://www.zentut.com/sql-tutorial/primary-key-constraints/ There are several rules that a primary key must follow Last one in list: There is a restriction on the data type of the primary key column e.g., it cannot be BLOB, CLOB, ARRAY or NCLOB. https://www.theserverside.com/discussions/thread/22917.html More of the same: Not a good idea for PK because it cannot be indexed. https://www.ibm.com/support/knowledgecenter/en/SSGU8G_11.70.0/com.ibm.sqls.doc/ids_sqs_0518.htm You cannot place a unique or primary-key constraint on a BLOB or CLOB column. UPDATE: Digging deeper, I see these primary keys are all 16 character HEX values, but they translate to blobs since they are a blend of characters and numbers. Per all the database research I have done recently on this, they still are inefficient primary keys. Another reference, specifically on HEX primary keys: https://stackoverflow.com/questions/5325766/is-it-ok-to-use-hexs-as-database-ids Thanks, Aaron PS - Off topic, but thanks to the database developer for placing cascade deletes on all Foreign Key Constraints! So easy to delete 1 target player's full slice of data that way... MUCH appreciated!