---
schema_version: "1"
id: 3cd4831ea1fb797f2f2579e1b1516bee66145bc84ebe2f23641885ba87c0c9bb
title: Big Objects Best Practices
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/platform/big-object-impl-guide/guides/big-object/big-object-considerations.md
canonical_url: https://developer.salesforce.com/docs/platform/big-object-impl-guide/guide/big-object-considerations.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 3bc67a397ae734931acee56296247d73f5d4e759b5023d50aa524888b7ac7c0b
products:
  - Big Objects Implementation Guide
  - Platform Developer Content
---

# Big Objects Best Practices

A big object is unique because of its ability to scale for massive amounts of data.

|Required Editions|
|-----------------|
|Available in: both Salesforce Classic and Lightning Experience|
|Available in: **Enterprise**, **Performance**, **Unlimited**, and **Developer** Editions for up to 1 million records|

## Considerations When Using Big Objects

-   To define a big object or add a field to a custom big object, use either Metadata API or Setup.
-   Big objects support custom Lightning and Visualforce components rather than standard UI elements home pages, detail pages, or list views.
-   You can create up to 100 big objects per org. The limits for big object fields are similar to the limits on custom objects and depend on your org’s license type.
-   You can’t use Salesforce Connect external objects to access big objects in another org.
-   Big objects don't support encryption. If you archive encrypted data from a standard or custom object, it’s stored as clear text on the big object.

    If you’re using Salesforce Shield Platform Encryption, standard or custom object field history is encrypted. For field history, data is archived using the Shield field history archive. Big objects respect encryption at rest.

    Shield Platform Encryption isn’t otherwise supported for custom big objects.


## Design with Resiliency in Mind

The big objects database stores billions of records and is a distributed system that favors consistency over availability. The database is designed to ensure row-level consistency.

When working with big data and writing batches of records using APIs or Apex, you can experience a partial batch failure while some records are written and others aren’t. Because the database is highly responsive and consistent at scale, this type of behavior is expected. In these cases, simply retry until all records are written.

Keep these principles in mind when working with big objects.

-   The best practice when writing to a big object is to have a retry mechanism in place. Retry the batch until you get a successful result from the API or Apex method.

    **tip:** To add logging to a custom object and surface errors to users, use the `addError()` method. See [An Introduction to Exception Handling](https://developer.salesforce.com/page/An_Introduction_to_Exception_Handling).

    **tip:** To verify that all records are saved, check the `Database.SaveResult` class. See [SaveResult Class Reference](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_database_saveresult.htm) .

-   Don’t try to figure out which records succeeded and which failed. Retry the entire batch.
-   Big objects don’t support transactions. If attempting to read or write to a big object using a trigger, process, or flow on a sObject, use asynchronous Apex. Asynchronous Apex has features like the `Queueable` interface that isolates DML operations on different sObject types to prevent the mixed DML error.
-   Because your client code must retry, use asynchronous Apex to write to a big object. By writing asynchronously, you’re better equipped to handle database lifecycle events.

**See Also**  


-   [*Salesforce Help:* Big Objects](https://help.salesforce.com/articleView?id=custom_index.htm)