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.