When would you use Custom Settings vs Custom Metadata Types?

Both store configuration data instead of business records, but they have very different lifecycles.

Custom Settings are like lightweight tables specifically for app configuration. Two flavours:

• List Custom Settings — singleton records keyed by name (e.g., Region_Tax_Rates__c with one record per region).
• Hierarchy Custom Settings — values that override per profile or per user (e.g., default settings for the org, with overrides for specific users).

Their key feature: Apex getInstance() reads them straight from the application cache — extremely fast, no SOQL governor cost.

The catch: Custom Settings data is not deployable. The metadata (the table definition) deploys; the rows inside do not. You re-enter values in production manually. They also can't be packaged with managed apps in the same way as metadata.

Custom Metadata Types are the modern alternative. They look like Custom Settings (named records, key-value style) but the records themselves are deployable metadata — you build them in a sandbox, deploy via change sets or Salesforce DX, and they land in production with the same values. They're also packageable, queryable from formulas (without SOQL governor cost), and queryable from validation rules.

Use Custom Metadata Types for almost all configuration today: feature flags, integration endpoints, business rules, region overrides, mappings.

Use Custom Settings when you need write access at runtime (Custom Metadata is read-only at runtime) or per-user overrides (Hierarchy Custom Settings still beat Custom Metadata for that pattern).