Beyond Archiving: Can Salesforce Big Objects Store Files?

This approach explores whether Salesforce Big Objects can be used beyond their intended purpose to store private files without additional File Storage, Data Storage, or external services. Files are split into Base64-encoded chunks stored in a custom Big Object, with Apex handling storage, retrieval, deletion, and access validation, while Lightning Web Components reconstruct files in the browser. However, Big Objects introduce important challenges, including restricted queries, no native record-level sharing, non-transactional operations, and governor limits. This is not a replacement for Salesforce Files, but an experiment in pushing the platform beyond its conventional use cases.

HACKS

jmelon

11/10/20262 min read

1. The Challenge

Salesforce Files is normally the preferred option for storing documents on the platform.

But what if additional File Storage or Data Storage isn't an option, and external services are off the table?

The challenge was to explore whether Big Objects, originally designed for large-scale data storage and archiving, could also store private files.

The idea was simple: split each file into Base64-encoded chunks, store them in a Big Object, and reconstruct the original file on demand.

Could it work within Salesforce's limits?

Each functional record stores only the file metadata:

FileKey__c
FileName__c
MimeType__c
FileSize__c
ChunkCount__c
StorageStatus__c

The actual content is stored separately in a custom Big Object.

2. Define the Big Object

The FileChunk__b Big Object contains:

FileKey__c: Private identifier shared by all chunks.
ChunkNumber__c: Position of the chunk.
Payload__c: Base64-encoded content.

Its composite index contains FileKey__c followed by ChunkNumber__c.

This order is important because Big Object queries must follow the indexed fields in the order in which they are defined.

3. Split and store the file

The Lightning Web Component reads the selected file and divides it into 48 KB chunks.

Each chunk is converted to Base64 and sent separately to Apex.

Big Objects do not support conventional insert operations, so every chunk is stored using Database.insertImmediate():

The file remains in an Uploading state until Apex verifies that every expected chunk exists. Only then is its status changed to Ready.

4. Rebuild the file

During download, Apex retrieves the chunks using the composite index:

The LWC requests the chunks in small batches, decodes the Base64 payloads, and reconstructs the original file as a browser Blob.

The private file key is never sent to the client.

5. Security considerations

Big Objects do not use the traditional Salesforce record-sharing model.

Users should therefore never receive direct access to FileChunk__b. Every upload or download must go through an Apex authorization layer that verifies:

The user is authenticated.
The user can access the parent record.
The file is assigned or available to that user.
The file is complete and in the Ready state.

Only after these validations should Apex resolve FileKey__c and access the Big Object.

6. Lessons Learned and Limitations

This experiment demonstrates that Salesforce Big Objects can store and retrieve files, but making it work doesn't necessarily make it the right architectural choice.

There are important trade-offs to consider:

No native record-level sharing; access must be enforced through Apex.
Restricted SOQL queries and index requirements.
Non-transactional operations requiring explicit integrity checks and cleanup.
Governor limits, particularly when processing large files or multiple chunks.
Finite Big Object record allocation and Base64 storage overhead.

The approach was tested with bounded file sizes and controlled upload and download volumes. For example, a 509 KB PDF divided into 48 KB chunks requires 11 Big Object records.

This is not a replacement for Salesforce Files or a general-purpose document management system.

The real takeaway? Sometimes exploring an unconventional use of a platform feature is just as valuable as finding the ideal solution.