Specifically, is it faster to query for a single record from a Custom Setting vs a Custom Object? Or is it about equal performance?

  • 3
    I’m voting to close this question because it looks like an X-Y Problem. – Phil W Jan 8 at 20:11

This feels a bit like an X-Y Problem question since Custom Objects and Custom Settings have very different purposes.

Custom Settings are designed to be cached by the system; you don't directly query them yourself, but instead use APIs to get them. These settings will, therefore, be faster to access than SObjects. You should also note that these settings are intended to be largely read-only so it would not be a good idea to use these for transactional data.

There are various limitations with Custom Settings (both in terms of the types of field you can use and in terms of record management) when compared with both custom objects and Custom Metadata Types.

The latter were introduced as a replacement for many usages of Custom Settings, and have the benefit that their instances can be packaged or included in Change Sets.

It very much depends on exactly what your use case is as to which of these three you would use.

  • Some additional context is that we are sunsetting a legacy loyalty system and moving it into SFDC. We need a way to assign loyalty numbers to new enrollments and the idea is to have a place that holds all of the unassigned loyalty numbers. When someone enrolls, grab an unassigned number for that enrollment and delete it from the list. I've obviously left a lot out, but that's the gist. – Zach Jan 8 at 20:18
  • If at all possible do this using a unique auto-number in Salesforce. Like I said, it seems like you're probably barking up the wrong tree. – Phil W Jan 8 at 20:22
  • Would love to but sadly it's not viable. Multiple brands roll up to a parent company that all use the same loyalty object and can have duplicate member numbers. You could think of it like a double primary key, brand + member number. – Zach Jan 8 at 20:30
  • I'm guessing you want to track unused/unassigned numbers so you can recycle them? Do the IDs have to be generated in a sequence? Is the total available range of IDs likely to be heavily populated, or can you rely on a relatively sparse ID domain? If you can, could you not handle this by actually creating a compound external ID that is a unique ID in Salesforce built from the brand and random member number, transiently generating several candidate unique IDs and checking if they exist. Assign the first one that doesn't exist. If the insert fails use the next candidate etc. avoids race condition – Phil W Jan 8 at 20:44
  • Oh, and could you introduce a new member numbering scheme for all new members that ensures uniqueness across the businesses, preserving previously allocated numbers for existing members, but never recycling either type of member number? – Phil W Jan 8 at 20:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.