Big Objects (The Good, The Bad, And The Ugly)

Blog:

Want to store a billion records? Then Big Objects may be for you. Be wary though, there’s only a handful of ways it’s meant to be used. It’s also a tool that isn’t as intuitive as you’d expect.

I still remember hearing conversations from previous employers along the lines of “Why does Salesforce’s storage cost me $$$ but it’s less storage than the phone in my hand?” Admittedly, there was a lack of understanding from management at those jobs about the structure of Salesforce’s systems, but it didn’t invalidate their arguments entirely. Part of providing a great service to your clients means storing data…a LOT of data. So now you’re caught between a rock and a hard place in finding balance between storing a bunch of data without breaking the bank.

Salesforce heard the community outcry a few years ago. Big Objects have come a long way since they were first released. Now they’re easier to work with, and there is more documentation out there. It’s not an entirely new concept either. If you’ve ever worked with History records like below, then you’re familiar with them.

Big Objects, at their heart, are designed to handle a few fields but billions of records for your company’s needs. Salesforce’s Trailhead on the subject provides a great explanation, but I’ll also dive into a website visit tracker demo. While this doesn’t interface with anything outside the Big Object, it’s so difficult to imagine this being useful for Accounting and other high-volume data points in your process. I’ll only show what this can do if you were to track every page a user is visiting.

First, you’ll need to go to your setup and search for Big Objects. Create a new one and name it appropriately. Be careful, once you’ve deployed this to Production, that’s it. You can’t go back.

The first thing I want to point out is the object API suffix notation. Notice the “__b” for Big Object. That is helpful to know when you’re looking at code I’ll show later.

Next, create fields. When creating some, you get fewer options than normal due to the limitations of Big Objects. I’ll start off with the Date/Time the website visit occurred and the URL.

Now that I have the fields created below, my next step is to populate the database.

Salesforce provides some developer documentation on how to insert records here. A simple snippet to insert a row would be below.

When working with these structures, my next instinct was to create a report on what I just built…WRONG. When working with potentially Billions of records, you can’t create reports directly in Salesforce for Big Objects. Instead, you’ll need a developer to write Async SOQL and summarize datapoints into a new custom object. Salesforce goes in-depth here about that process.

Below are some things to keep in mind when working with Big Objects. Like I said earlier, they’re great at handling transactional records but not much more than that. Check out the rest on the Trailhead module describing the limitations.

• Big Objects support only object and field permissions. That’s different than all the sharing rules you’ll repeatedly hear about.
• Big Objects support custom Salesforce Lightning and Visualforce components rather than standard UI elements (home pages, detail pages, list views, and so on). Because Salesforce can’t guarantee when a query will finish, they gutted it from being used in a lot of UI interactions.