Big Objects
Big Objects are a Salesforce object type designed to store billions of records, far beyond the practical limits of standard or custom objects.
Definition
Big Objects are a Salesforce object type designed to store billions of records, far beyond the practical limits of standard or custom objects. They are the platform's answer to scenarios that need long-term retention of event-level data: archived transactions, audit logs, IoT telemetry, regulatory snapshots, multi-year activity histories. Big Objects trade off some traditional Salesforce features (no triggers, no validation rules, limited reporting) in exchange for the ability to query records at massive scale via async SOQL.
Each Big Object is defined by metadata that includes its fields and its composite primary key. The primary key is the access pattern, not just a uniqueness constraint. Big Objects are indexed only on this composite key, which means queries must filter on key fields to perform well. Async SOQL handles cross-cutting aggregations against Big Objects, returning results to a custom object as a Background Job. Big Objects do not appear in standard reports or list views; they exist for programmatic and analytical access at a scale no other Salesforce data store can match.
How Big Objects scale Salesforce to billions of records
When Big Objects fit and when they do not
Big Objects fit when the data is append-only or rarely updated, when the volume genuinely exceeds what custom objects can handle (more than 100 million records), and when queries are mostly key-based or aggregated. Common use cases: archived audit trails, historical activity events, IoT sensor readings, compliance snapshots. Big Objects do not fit when the data needs to participate in triggers, validation rules, sharing rules, reports, or list views; standard custom objects remain the right choice for that.
The composite primary key and access patterns
Each Big Object has a composite primary key made of one or more fields, defined at type creation. The primary key is the only index. Queries must filter on the key prefix to be efficient: if the key is (UserId, EventDate, EventType), queries should filter on UserId first, then UserId plus EventDate, and so on. Filtering only on EventType without the leading key fields produces a slow scan. This is fundamentally different from custom objects, which can have arbitrary indexes; Big Objects force you to design the access pattern up front.
Two flavors: Custom Big Objects and Standard Big Objects
Custom Big Objects are admin-defined and have the __b suffix. They store whatever data the customer needs. Standard Big Objects are platform-provided for specific features: FieldHistoryArchive holds long-term field history, AsyncOperationLog holds platform event processing history, ProductTransfer history holds inventory movements. Custom Big Objects need careful design; Standard Big Objects are pre-built and just need querying.
Async SOQL and the background query model
Standard SOQL on Big Objects supports only key-based filters and returns up to 50,000 records, which is rarely enough. Async SOQL is the answer for analytical workloads: submit a query through the Async SOQL API, and the platform runs it in the background, writing results to a custom object record-by-record. Async SOQL supports more powerful query patterns including non-key filters and aggregations, at the cost of being asynchronous and rate-limited. Plan async SOQL jobs into your batch processing schedule rather than expecting interactive responses.
DML operations: insert and delete only
Big Objects support insert and delete, but not update. To "change" a record, you delete the old one and insert a new one with the corrected data. This append-only model fits archive and event-data use cases naturally; it would be painful for any data type that needs mutation. The Database.insertImmediate method inserts a single Big Object record synchronously; the more common pattern uses Apex Batch with the standard insert statement for bulk loads.
Storage costs and licensing
Big Object storage is licensed separately from standard data storage. Most orgs get a baseline allocation (one million Big Object records) included with Salesforce Platform licenses, with additional capacity sold in million-record blocks. Plan storage costs as part of the architecture; a Big Object that grows to 500 million records can produce a significant Salesforce invoice line item. Salesforce Optimizer and Setup > Storage Usage track current consumption against the entitlement.
Common patterns: archival, audit, IoT, snapshots
Archival: use Big Objects to retain historical transactions after the standard object retention window passes, freeing storage on the live object while keeping data queryable for compliance. Audit: capture every field change as an event row in a Big Object for tamper-resistant audit history. IoT: ingest sensor readings as Big Object inserts via Streaming API or Platform Events with downstream Apex. Snapshots: take periodic point-in-time captures of business state for reporting that does not need real-time data. Each pattern has a published reference architecture in Salesforce Architects.
How to design and create a Big Object
Big Object design is the hardest part. The composite primary key locks in the access pattern; getting it wrong makes the entire object unusable for the planned workload. Sketch the queries you need to run before defining the primary key, validate with realistic data in sandbox, and plan storage costs against the projected volume.
- Confirm Big Object is the right tool
Volume genuinely exceeds 100 million records, data is append-only, queries are mostly key-based or aggregate. If any of these are not true, a standard custom object with proper indexing usually fits better and gives you triggers, validation rules, and reporting.
- Design the composite primary key first
List the queries you need to support. The leading fields of the composite key must appear in every query filter. Common patterns: (TenantId, EventTime, EventType) for multi-tenant audit logs; (DeviceId, ReadingTime) for IoT telemetry. The order matters: leftmost field is the most-selective filter.
- Create the Big Object metadata
Setup > Big Objects > New. Provide label, plural label, API name (will get __b suffix), and the composite primary key field list with order. Big Objects can be created only through Metadata API in some cases; check current platform support.
- Add custom fields and the indexed key fields
The fields named in the composite primary key are the indexed fields. Other fields are stored but not indexed; you cannot query on them efficiently. Plan field types carefully because schema changes are limited after data is loaded.
- Deploy via Metadata API or change set
Big Object metadata deploys like any other custom object. The deployment includes the type definition and the primary key configuration. Deploy to sandbox first and validate the schema before loading any data.
- Load data via Bulk API 2.0 or Apex insert
For initial loads, use Bulk API 2.0 with the __b suffix object. For ongoing loads, Apex insert via Batch Apex handles the volume cleanly. Each Big Object insert counts against the daily DML governor allotment.
- Query with standard SOQL for key-based access
SELECT Field__c FROM My_BigObject__b WHERE KeyField1__c = ''X'' AND KeyField2__c = ''Y''. Filters must lead with the composite key fields. Non-key filters force a full scan that hits the 50,000 record cap.
- Use Async SOQL for analytical workloads
Submit Async SOQL via the REST API endpoint. Specify the query, the destination custom object, and the field mapping. The platform runs the query in the background and populates the destination object record-by-record. Monitor the job status via Background Jobs.
The indexed key that determines query performance. Leading fields must appear in every efficient query filter.
Custom for admin-defined data with __b suffix. Standard for platform features like FieldHistoryArchive.
The custom object that receives Async SOQL query results. Required for analytical queries that exceed standard SOQL limits.
- Big Objects do not support triggers, validation rules, sharing rules, workflow, or process automation. Inserting a record bypasses all the standard save-event hooks, which is intentional but easy to forget.
- The composite primary key is the only index. Queries that do not filter on the leading key fields hit a full-scan path that is slow on large volumes and capped at 50,000 records.
- Big Objects support insert and delete, not update. Mutation requires delete followed by insert, which is awkward for any data that changes after initial creation.
- Async SOQL is rate-limited and asynchronous. Plan analytical queries into batch schedules rather than interactive dashboards because results may take minutes or hours.
- Storage costs scale with volume and licensing tier. A Big Object that grows to hundreds of millions of records can produce a significant invoice line item beyond the standard entitlement.
Trust & references
Cross-checked against the following references.
- Big Objects OverviewSalesforce Help
- Big Object Developer GuideSalesforce Developer
- Async SOQLSalesforce Developer
Straight from the source - Salesforce's reference material on Big Objects.
- Define a Big ObjectSalesforce Help
- Big Object Developer GuideSalesforce Developer
- Big Object IndexesSalesforce Developer
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
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…