Salesforce Big Objects: Complete Guide
Quick Summary:
Big Objects store massive data volumes (hundreds of millions of records) that standard custom objects aren't built to handle -- commonly used for long-term archival data that needs to remain queryable.
What Is a Big Object?
A Big Object is a specialized object type built for genuinely massive data volumes, using a different underlying architecture than standard custom objects. In exchange for that scale, Big Objects trade away most standard automation capability (triggers, most Flow support) -- they're built for storing and querying large historical datasets, not for active transactional business processes.
⚠️ Before You Start
Big Objects are not a drop-in replacement for a standard custom object at scale. If you need active automation, validation rules, or standard reporting on the data, a Big Object is the wrong tool -- it's specifically for large-volume, low-write-frequency archival use cases.
How to Set One Up
Go to Setup → Big Objects and click New Big Object.
Define the fields, including at least one indexed field for query performance.
Deploy the Big Object definition (this typically requires metadata deployment rather than simple point-and-click activation).
Load data via Bulk API or Apex.
Query using Async SOQL, since standard synchronous SOQL isn't used for Big Object queries.
A Real-World Example
A company needs to retain 7 years of detailed transaction history for compliance, representing hundreds of millions of records -- far beyond what's practical to keep as an actively-automated standard custom object. Moving this historical data into a Big Object keeps it queryable for compliance audits and historical reporting, without the storage cost or performance impact of keeping it in standard object storage.
💡 Pro Tip
Plan your indexed fields carefully before deploying -- Big Object query performance depends heavily on querying through indexed fields, and this is harder to retrofit after large volumes of data are already loaded.
Frequently Asked Questions
How is a Big Object different from a standard custom object?
Big Objects are built for massive data volumes (hundreds of millions to billions of records) with a different underlying architecture, trading some standard object features (like triggers and most automation) for scale.
Can Big Objects support standard automation like Flow and validation rules?
No, Big Objects have significant limitations here -- they're designed for storing and querying large historical datasets, not for active transactional automation.
How do I query data in a Big Object?
Via Async SOQL (asynchronous queries designed for the scale Big Objects operate at) rather than standard synchronous SOQL used on regular objects.
What\'s a common use case for Big Objects?
Archiving historical data -- old activity logs, expired records, audit trails -- that needs to remain accessible for compliance or reporting but doesn't need active day-to-day transactional access.
Do Big Objects count against standard storage limits?
No, Big Objects have separate storage allocation and pricing from standard object storage, which is part of why they're cost-effective for very large archival datasets.
Can Big Object records be edited after creation?
Big Objects are primarily designed for insert and read operations -- update and delete capabilities are more limited compared to standard objects.
Can I build reports directly on Big Object data?
Not through standard reports -- Big Object data is typically surfaced through custom UI querying Async SOQL, or exported/integrated into other reporting tools.
Is there a data volume threshold where Big Objects become worth considering?
Generally, once you're dealing with tens of millions of records that need long-term retention without active transactional needs, Big Objects become worth evaluating over standard custom objects.
Can Big Objects be used with External Objects for a hybrid approach?
They serve different purposes -- External Objects surface data live from an external system without storing it in Salesforce; Big Objects store large volumes directly within Salesforce's big-data architecture.
Do I need special licensing to use Big Objects?
Big Objects require appropriate storage allocation, which may need to be purchased separately depending on your org's needs and existing allocation.