Big Objects
Big Objects is a Setup feature for managing Salesforce Big Objects, which are designed to store and manage massive volumes of data (billions of records) on the Salesforce platform.
Definition
Big Objects is a Setup feature for managing Salesforce Big Objects, which are designed to store and manage massive volumes of data (billions of records) on the Salesforce platform. Unlike standard objects, Big Objects are optimized for large-scale data storage and retrieval using a defined index, making them suitable for historical archiving and audit data.
In plain English
“Here's a simple way to think about it: Big Objects exist for the data Salesforce was never built to hold. Standard objects strain at tens of millions; Big Objects are built for billions. Trade rich query patterns for horizontal scale.”
Worked example
A database architect at Compass Finance needs to track every field change on sensitive Account fields for seven years. Standard audit logs don't go that long and Field History Tracking is capped at 18 months. She defines a Big Object "Audit_History__b" with Composite Primary Key fields (Record_Id__c, Field_Name__c, Change_Timestamp__c) and additional fields for Old Value and New Value. A record-triggered Flow inserts a Big Object row on every qualifying field change; Async SOQL queries retrieve the archive for compliance audits. The Big Object handles tens of millions of historical rows without affecting standard data storage limits.
Why Big Objects exist for the data Salesforce was never built to hold
Standard Salesforce objects start to strain at tens of millions of rows. Big Objects are the platform's answer for the workloads that need billions: years of clickstream events, IoT telemetry, healthcare claims history, archived activity from a decade of past customers. They trade the rich query patterns of standard objects for a defined index and a constrained query language, and in return give you horizontal scale that the rest of the platform can't.
The trade-off is the whole point. You cannot run a list view, a report, or an arbitrary SOQL filter against a Big Object the way you would an Opportunity. You query it through the index you defined when you created it, or through Async SOQL when you need a wider sweep. Designing the index correctly the first time matters far more than for a normal object - change it later and you may need to migrate billions of rows. Big Objects are the right answer for archive and audit workloads; they are the wrong answer for anything that wants the standard CRM ergonomics.
How to set up Big Objects
Big Objects store billions of records on the Salesforce platform — historical activity, archive data, IoT-scale audit trails. Different SOQL behavior than standard / custom objects (asynchronous queries, fewer field types). Setup is via Custom Metadata-style declarative config OR via Apex with createBigObject(); production Big Objects are typically deployed via Metadata API.
- Confirm Big Objects is licensed
Some editions include a baseline; high-volume use requires add-on capacity.
- Open Setup → Big Objects
Setup gear → Quick Find: Big Objects → Big Objects.
- Click New Big Object
Wizard or Metadata API — Big Objects support declarative creation in Setup.
- Set Label, Plural Label, Object Name
Object Name auto-derives with __b suffix (vs __c for custom objects).
- Add Custom Fields (limited types)
Big Objects support a smaller field type set than Custom Objects — Text, Number, Date/Time, Lookup, External ID. No formulas, no rollups.
- Define an Index (required)
Big Objects require an explicit index for queries — typically (CreatedDate, RecordId) or (LookupField, CreatedDate). Without an index, queries are impossible.
- Save
Big Object is created. Now insert records via Apex insertImmediate() or the Bulk API.
- Query asynchronously via Async SOQL
Big Object queries don't run synchronously like SOQL on standard objects. Use Async SOQL or paginated SOQL queries via the index.
__b suffix.
Text / Number / Date/Time / Lookup / External ID. No formulas / rollups.
Required. Defines query patterns.
- Big Objects can't be queried like standard SOQL. Queries must use the defined index — non-indexed queries fail. Plan indexes carefully upfront.
- Big Objects don't support all Custom Object features — no triggers, no validation rules, no Apex sharing, no UI list views. Designed for archival and high-volume storage, not interactive admin.
- Once data is in a Big Object, deleting individual records is hard. Salesforce supports schema-level Big Object deletion (drop the table) but not row-level UI delete in the same way as Custom Objects.
How organizations use Big Objects
10 years of clickstream data in Big Objects; standard objects would have collapsed at that volume.
IoT telemetry from medical devices stored in Big Objects; billions of events queryable through the index.
Trust & references
Straight from the source - Salesforce's reference material on Big Objects.
- Manage Big ObjectsSalesforce Help
Test your knowledge
Q1. Can a Salesforce admin configure Big Objects without writing code?
Q2. What is the primary benefit of Big Objects for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Big Objects?
Discussion
Loading discussion…