What are Salesforce Big Objects? A Practical Guide

Posted by Vinay Vernekar 27th October 2025

Getting Real with Salesforce Big Objects

Ever had a client ask to store 500 million logs in a custom object? You know that’s a recipe for disaster. That’s where Salesforce Big Objects come in. They are built specifically for those massive datasets that would otherwise tank your org performance and hit every governor limit in the book.

Look, I’ve seen teams try to force historical data into standard objects just because they’re comfortable with them. But if you’re looking at hundreds of millions of rows, you’ll hit a wall fast. Salesforce Big Objects are the solution for long-term storage where scale matters more than real-time updates. They can handle billions of records without breaking a sweat.

The stuff that trips people up

Here’s the thing: these objects don’t behave like the ones you’re used to. They’re immutable. That means no triggers, no workflow rules, and very limited DML. If you need to change a record, you basically have to overwrite it using the same primary index. It’s a different way of thinking about data.

When you’re managing Salesforce large data volumes, you have to accept that Big Objects aren’t for your daily transactional work. They’re for the “write once, read occasionally” patterns like audit trails or forensic analysis. And don’t expect to see them in the standard Report Builder either – you’ll need other tools for that.

A technical architecture diagram showing the flow of data from standard Salesforce records into a high-capacity Big Object storage structure.
A technical architecture diagram showing the flow of data from standard Salesforce records into a high-capacity Big Object storage structure.

When to pull the trigger on Salesforce Big Objects

So when should you actually use them? In my experience, it usually comes down to three scenarios. First is event logging. If you’re tracking every single click or API call, a regular object will explode. Second is historical archiving. If you need to keep seven years of snapshots for compliance, this is your best bet.

But honestly, most teams get this wrong by not planning their index. You have to define a composite primary index of up to five fields. This index is the only way you can query the data efficiently. If you don’t include a field in your index, you can’t use it in a standard SOQL filter. It’s that simple.

A standard example: EventLogFile

Salesforce actually gives you some of these out of the box. The most common one is EventLogFile. It’s what powers Event Monitoring. It tracks things like logins, Apex executions, and URI clicks. Because this data gets huge fast, Salesforce stores it as a big object to keep it out of your regular data storage limits.

Typical fields you’ll see in there include:

  • EventType: What happened (like a Login or API call).
  • LogDate: When it happened.
  • LogFile: The actual data payload of the event.

Querying without the headache

Now, how do you get data out? For small sets, you can use standard SOQL if you follow the index rules perfectly. But for the heavy lifting, you’ll want to use Async SOQL. It runs in the background and is much better at handling those massive scans.

SELECT Id, EventType, LogDate 
FROM EventLogFile 
WHERE EventType = 'API' 
AND LogDate >= 2024-01-01T00:00:00Z

Since this is asynchronous, you’ll submit the query and then poll the status. It’s a bit like how asynchronous Apex limits work – you trade immediate results for the ability to do much more work in the background.

One thing I always tell juniors: your primary index is everything. If you mess up the field order in your index, your queries will be useless. Think about how you’ll search for the data before you even create the object.

Key Takeaways for Salesforce Big Objects

  • Scale is king: Use them for millions or billions of records that don’t need triggers.
  • Index first: Your query performance lives and dies by your composite primary index design.
  • Read-only mindset: Treat the data as immutable; don’t expect to do “Edit” and “Save” operations.
  • Async is your friend: Use Async SOQL or the Bulk API to move large chunks of data without hitting limits.
  • Reporting: You won’t find these in standard reports, so plan for Tableau, CRM Analytics, or custom LWC displays.

At the end of the day, Salesforce Big Objects are a specialized tool. They aren’t a replacement for custom objects, but they’re a lifesaver when your data growth starts to outpace your storage budget. Just remember to spend extra time on your index design – it’s the one thing you really don’t want to fix later.

Tags: