Big object capabilities and limitations
Key Takeaway
Plan a big object's index before you deploy, because SOQL on a big object works only on the index fields in index order, and you can't edit or delete the index afterward.
Big objects store and manage massive amounts of data on the Salesforce platform. To work at that scale, they give up many features that standard and custom objects have. So they fit archives, audit history and very large customer data sets, but not everyday CRM records.
What big objects are
Big objects keep consistent performance at a billion records or more. Your org or an external system can reach them through a standard set of APIs.
There are two kinds of big objects. Salesforce defines standard big objects and includes them in Salesforce products. For example, FieldHistoryArchive is part of Field Audit Trail and stores up to 10 years of archived field history to help meet audit and data retention rules.
Custom big objects are ones you define and deploy yourself, using Setup or Metadata API. Their names end in __b, as in Phone_Book__b. Custom big objects are built for these main use cases:
- A 360-degree view of the customer, such as loyalty, transaction, order and billing details.
- Auditing and tracking how users use Salesforce over the long term.
- A historical archive that keeps old data available for analysis or compliance while core CRM apps stay fast.