• The SF GUIDs are a max of 18, so CHAR(18) although I've seen different systems (DBAmp OLE DB driver for one) declare them as NCHAR(18). You will almost certainly want to keep/store these so you can have lineage/reference to the source record, so you're going to be hit with the 18bytes (or 36 if you use NCHAR) per row anyway. Adding a bigint will use 8bytes.

    For me, I would assume that the bigint PK/FK and indexing performance *would* be better than using the natural key but you will have some significant overhead in your ETL in adding the surrogate, also every lookup will come down to you with the PK GUID of the lookup object.

    It almost comes down to how much data, which would impact the performance of an indexed string versus the performance of bigint.

    Steve.