Big Objects are Salesforce storage structures designed for very large data volumes over long retention periods. In this context, they are used to store and query event data at scale, supporting historical analysis while preserving performance for operational systems.
What Big Objects Are in Salesforce
Big objects are designed for durable, high-volume storage where the main requirement is retaining very large datasets and querying them efficiently without burdening day-to-day operational workloads. They fit historical, audit-like, and event-driven use cases better than active transactional records.
Why Big Objects Exist
The core design goal is scale with predictable performance. Instead of treating all data as live operational data, Big Objects let teams preserve long time horizons for analytics, compliance, or traceability while keeping the primary application data model responsive. That separation matters when event histories, logs, or archival records would otherwise create storage pressure or slow normal business processes.
In practice, this makes Big Objects a data architecture choice as much as a Salesforce feature. They are most useful when retention is important, query patterns are known in advance, and the organisation can accept a more constrained access pattern than with standard objects.
How Big Objects Work
Big Objects are not general-purpose records stores. They are built for append-heavy, large-scale persistence and indexed querying rather than frequent updates, relational flexibility, or ad hoc filtering. That means the data model and index design have to be planned around the questions you expect to ask later.
Because the platform optimises for scale, the trade-off is reduced flexibility. Developers and architects usually treat Big Objects as a destination for historical or telemetry-style data, where the structure is stable and the value comes from long-term retention and retrieval at scale.
For security and governance, that same structure means you should think carefully about what data is retained, how long it is kept, and whether the stored content includes sensitive operational traces, user activity records, or other information that may need tighter classification and access review.
Common Uses and Design Trade-Offs
Big Objects are commonly used for event history, log retention, audit trails, and other datasets that accumulate continuously over time. They are a good fit when the organisation needs durable storage and queryable history, but does not need the full interaction model of standard Salesforce records.
The main trade-off is that scale comes with constraints. Big Objects are intentionally less flexible than standard objects, so they work best when teams define the schema, indexing strategy, and retention expectations up front. If the data needs frequent updates, rich relationships, or highly dynamic search behaviour, another storage pattern is usually a better fit.
That design choice also influences operational governance. If historical data is retained for evidence, reporting, or investigation, teams should align the storage model with data retention policy, audit needs, and access boundaries before large volumes accumulate.
Risk and Threat Considerations
Big Objects often store the kinds of records that security teams later depend on for investigations, so the main risk is not the storage feature itself, but the consequence of putting sensitive history into a system that may be under-governed. Long retention can expand exposure if access controls, classification, or retention limits are not tightly managed.
Failure mechanism: Oversized historical stores can accumulate unnecessary sensitive data, and weak indexing or query design can make it harder to retrieve evidence efficiently during incident response or audit review.
Impact: Poorly governed retention can increase privacy exposure, complicate investigations, and turn a useful archive into a long-lived source of compliance and access risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Big Objects often retain long-lived event and audit history. |
| AC-6 — Least Privilege | Long-retained data increases exposure if access is too broad. | |
| PM-5 — System Inventory | Archival data stores need ownership and visibility to remain governed. | |
| Recommendation — Set retention rules for historical records and keep only evidence needed for audit and investigation. Limit access to historical datasets to the smallest set of users and processes that need it. Inventory Big Objects as governed data stores with named owners and retention intent. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Big Objects hold governed information assets that must be identified. |
| A.8.10 — Information deletion | Long retention makes controlled deletion a material governance issue. | |
| Recommendation — Record Big Objects in the information asset inventory and assign ownership. Define deletion and retention rules for archived data stored in Big Objects. | ||
Practitioner Guidance
Governance implication: Treat Big Objects as a deliberate retention and evidence layer, not just a storage convenience. Define what belongs there, how long it should remain, and which business or security use case justifies the retention.
What to watch for: If the dataset starts to collect broad operational detail, personal data, or records with unclear ownership, reassess whether the storage design still matches the intended control and reporting purpose.
Practitioner takeaway: Big Objects work best when the schema, retention intent, and downstream investigation use case are all clear before the data volume becomes significant.
Related resources from NHI Mgmt Group
- How should security teams prevent valid credentials from accessing the wrong API objects?
- What breaks when Entra ID recovery only restores deleted objects?
- How should teams handle stale Active Directory objects before access reviews?
- Why do nested objects create authorization risk in search systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
