A Big Object is a Salesforce object type designed for storing billions of rows of data, much higher volume than standard or custom objects can practically handle.
Characteristics:
- API name suffix `__b` distinguishes them.
- Index-driven access only — you query Big Objects via SOQL using the index field(s) you defined when creating the Big Object. You cannot query without an index hit.
- No reports / list views / Lightning page support — Big Objects don't appear in standard reports or list views.
- No standard triggers, validation rules, formula fields, or workflow — they're storage-only.
- Async loading and async query — most operations on Big Objects use the Bulk API or Async SOQL, not standard sync APIs.
- Storage cost — much cheaper per row than standard data storage.
Common use cases:
- Audit log archive — moving old Activity History or Opportunity History rows out of standard storage into a Big Object for long-term retention.
- IoT / sensor data — high-volume time-series data (temperature readings, device events).
- Compliance retention — regulatory requirements to keep records for 7-10 years; standard objects can't economically scale.
- Customer interaction history — every touchpoint across email/web/app, retained beyond the 24-month EAC window.
Limitations:
- Limited data type support (Text, Number, Date, Lookup-by-index).
- Query patterns must be designed up-front; ad-hoc queries don't work.
- Reporting requires CRM Analytics or external warehousing, not standard reports.
Big Objects are powerful but specialised. They're not a general-purpose storage solution — they're for the specific case of "I have billions of rows that I read by a known key, rarely write, and never need to traverse arbitrarily".
A common admin question: "should I use a Big Object?" Default answer: probably not, unless you've confirmed standard storage genuinely won't scale.