Salesforce data archiving: Big Objects, Data Cloud, and the delete decision nobody wants to make

Every mature Salesforce org eventually hits the same wall: data storage is full, the overage line on the renewal is not small, and the moment anyone proposes deleting old records, three departments materialize to explain why those exact records can never, ever be touched — audit, legal, “the CFO looks at year-five trends.” So the data stays, the org keeps swelling, list views crawl, report timeouts creep in, and the storage bill compounds. Archiving is the way out, and it’s one of the least glamorous, most consistently botched projects on the platform.

It gets botched because teams treat “archive” as one decision when it’s really three: where does the cold data go, how will anyone query it afterward, and what are we actually allowed to delete from production. Get the destination right and the query story wrong, and you’ve built a compliance archive nobody can read — which surfaces the day an auditor asks for five-year-old records and your “archive” turns out to be a Bulk API export sitting in an S3 bucket with no index. This is the guide to the three real destinations — Big Objects, Data Cloud / Data 360, and external storage — how each one queries, what each costs, and the delete decision you can’t dodge forever. It’s the same altitude-of-tool thinking behind our take on Salesforce technical debt: the cheapest tool that fits the job usually wins, but only if you know how the job ends.

First, know which limit you’re actually hitting

Before you archive anything, be precise about the constraint, because two different Salesforce storage limits get conflated and they have different fixes.

Data storage is the row-count-driven allocation — most standard records are billed at roughly 2 KB each regardless of how many fields they have, so the meter is really counting records, not bytes. This is the one that fills up from years of accumulated Tasks, EmailMessages, closed Cases, and integration logs. File storage is separate — attachments, ContentVersion, documents — and archiving records does nothing for it. If your overage is file storage, this whole post is the wrong tool; you want a document-offload strategy, not record archiving.

Assuming it’s data storage: the highest-volume offenders are almost never your core business objects. They’re the exhaust — activity records, field history, integration staging, event logs, and the giant custom object some integration has been inserting into hourly since 2021. Run the storage usage breakdown in Setup before you design anything. Archiving the wrong object is effort spent on a rounding error while the real bloat keeps growing. A quick pass through the Org Health Scorecard is a reasonable way to surface where the data debt actually sits.

Option 1 — Big Objects: native, cheap storage with a strict query contract

Big Objects are Salesforce’s native answer for storing massive volumes of data on-platform. Two facts make them attractive as an archive target: they scale to billions of records, and their records are tracked under a separate storage allocation rather than your standard data storage — every org gets a default allowance of one million big object records, and you raise it by talking to your account executive. Move ten million closed activity records from a standard object into a Big Object and your data-storage overage problem largely evaporates, because those records no longer count against the allocation that was full.

The catch — and it’s the whole catch — is the query contract. A Big Object isn’t a normal sObject you can slice however you like. When you create one, you define a composite index (a small set of fields, in a fixed order, forming the record’s primary key), and that index is the only efficient way in. You query with synchronous SOQL, but the WHERE clause has to filter on the indexed fields from the left, in order — you can filter on the first index field, or the first and second, but you can’t skip the first and filter only on the third. Design the index around the queries you’ll actually run, put the field you’ll filter on most in the first position, and understand that if a future question doesn’t fit the index, there’s no quick answer to it.

// Reading archived activity for one account, filtering left-to-right along the index:
// index order = (Account__c, Activity_Date__c, Archived_Task_Id__c)
List<Archived_Activity__b> rows = [
    SELECT Account__c, Activity_Date__c, Subject__c
    FROM Archived_Activity__b
    WHERE Account__c = :accountId
      AND Activity_Date__c >= :startDate
    LIMIT 5000
];

One more thing that trips people up, because the internet is full of stale tutorials: Async SOQL is retired. It used to be the way to run big background queries and aggregations over Big Objects, and it’s gone. Today your access paths are synchronous SOQL against the index, Batch Apex to process archived records in chunks, and the Bulk API to extract them wholesale to an external system. Plan reporting around those three, not around the Async SOQL you’ll still see in old blog posts.

Big Objects are the right call when the archived data is rarely read, filtered along a predictable key, and mostly kept for compliance and the occasional lookup. They’re the wrong call when someone will need to slice it fifteen different ways in a report — which is the exact need the next option exists for.

Option 2 — Data Cloud / Data 360: archive that stays analyzable

The weakness of a Big Object is reporting; the strength of Data 360 is reporting. If the reason you can’t delete old records is “we run trend analysis on them,” archiving into Data 360 keeps the data queryable at scale without it consuming CRM data storage — you ingest the records into a Data Lake Object, map them into the model, and analyze them there instead of in the transactional org.

There are two ways to do it, and they’re not equivalent. You can copy the data into Data 360 via the Ingestion API or a Data Stream and then delete it from CRM — a true archive that frees storage. Or, if the cold data already lives in a warehouse like Snowflake or BigQuery, you can leave it there and reach it through zero-copy federation, which never moves or duplicates it at all. The zero-copy path is elegant for warehouse-resident history; the copy-then-delete path is what you want for data that’s only in Salesforce today.

The honest trade-off is cost model and latency. Data 360 is metered on consumption — storage plus the processing and queries you run against it — so “archive to Data Cloud” is not free the way people assume; it moves the spend from a CRM storage line to a Data Cloud consumption line, and a chatty analytical workload against archived data can run up credits. Budget it against the Data 360 pricing and credits reality, not against a hope that it’s cheaper by default. And Data 360 is an analytical layer, not a transactional one — it’s for reporting on the archive, not for an agent to read a single archived record with millisecond latency inside a live conversation.

Data 360 is the right call when the archived data has to stay reportable and segmentable and you’re already invested in the platform. It’s overkill when all you need is compliance cold-storage with an occasional keyed lookup — that’s what Big Objects are for and they’re cheaper for it.

Option 3 — External storage: cheapest bytes, most engineering

The third destination is off-platform entirely — extract with the Bulk API into a data warehouse or object store (Snowflake, BigQuery, S3, Azure) and report on it with your BI tool of choice. This is the cheapest place to keep bytes and the most flexible place to query them, and it’s the standard move for very large, very cold datasets where neither native option is economical.

The cost you’re trading for those cheap bytes is engineering and integration risk. You own the extraction pipeline, the schema drift when someone adds a field in Salesforce, the re-hydration path for when a record has to come back into the org, and the access controls so the archive doesn’t become a shadow copy of regulated data sitting outside your Salesforce security model. Many teams reach for a purpose-built archiving ISV here precisely to avoid hand-building all of that — a legitimate choice, as long as you understand you’re buying the pipeline, not escaping it. Treat the connection like any other integration pattern: it has failure modes, and the archive is only as trustworthy as the pipeline that fills it.

The delete decision you can’t avoid

Here’s the part every archiving project tries to skip and none of them can: archiving only frees storage if you actually delete the source records from CRM. Copying ten million records into a Big Object and leaving the originals in place doesn’t reduce your data storage by a single kilobyte — you’ve now got the data twice and the same overage bill. The storage win is realized at the DELETE, and the DELETE is where the organizational courage runs out.

Make it a controlled, reversible, defensible process rather than a leap of faith:

• Verify before you delete. The archive write and the source delete must be transactionally disciplined — confirm the record landed in the destination before the source is removed, and reconcile counts. A half-finished archive that deletes records it never actually copied is data loss with extra steps.
• Delete in batches, and mind the Recycle Bin. Deleted records sit in the Recycle Bin consuming storage until it’s emptied or ages out, so a delete doesn’t reclaim space instantly. For very large purges, hard-delete via the Bulk API. Batch it to respect governor limits and to keep a bad run from cascading.
• Write the retention policy down first. The rule isn’t “delete old stuff,” it’s “records of type X older than N years, meeting condition C, are archived to destination D and purged from CRM” — a policy legal and compliance have signed, tied to your actual retention obligations. This is the same governed-lifecycle discipline behind honoring a right-to-be-forgotten request: data has a defined lifecycle, and deletion is a step in it, not an accident.
• Keep a re-hydration path. Occasionally an archived record has to come back — a reopened case, a legal hold, an auditor’s request. Know before you archive how a record gets read, or restored, from each destination, because “we can’t get it back” is how an archive becomes a liability.

What to actually do

Start by identifying the real constraint — data storage versus file storage — and the specific high-volume objects behind it; don’t design an archive for records that aren’t the problem. Then match the destination to how the data will be read after it moves: Big Objects for compliance cold-storage with predictable, indexed lookups; Data 360 for archived data that must stay reportable and segmentable; external storage for the largest, coldest datasets where cheap bytes justify owning a pipeline. Write the retention policy down, get it signed, and only then wire the archive-and-delete so the storage is actually reclaimed. Do it in that order and archiving stops being an annual panic about an overage invoice and becomes what it should be — a governed data lifecycle that keeps the transactional org fast and the historical record intact.

Understanding the basics

Do Big Objects count against Salesforce data storage limits?

No — big object records are tracked under a separate storage allocation, not your standard CRM data storage, which is what makes them useful as an archive target. Every org starts with a default allowance of one million big object records and you can raise it through your account executive. Moving high-volume historical records out of a standard object and into a Big Object removes them from the data-storage meter that was full. The trade-off is the query contract: you can only filter efficiently on the composite index you define when you create the object, from the left in order.

How do you query Big Objects now that Async SOQL is retired?

Async SOQL — once the way to run large background queries and aggregations over Big Objects — has been retired, so don’t design around it. Your current access paths are synchronous SOQL that filters on the composite index fields (from the left, in index order), Batch Apex to process archived records in manageable chunks, and the Bulk API to extract records to an external system for reporting. If you need flexible, multi-dimensional reporting over the archive rather than keyed lookups, that’s a signal to archive into Data 360 or an external warehouse instead of a Big Object.

Should I archive Salesforce data to Big Objects or Data Cloud?

Choose by how the data will be read after it moves. Big Objects are cheaper and native, and they’re right when the archived data is rarely read and looked up along a predictable key — compliance cold-storage. Data Cloud / Data 360 is right when the archived data must stay reportable and segmentable at scale, because it keeps the data analyzable without consuming CRM data storage — but it bills on consumption, so it moves the cost rather than eliminating it. For the largest, coldest datasets, an external warehouse is cheaper still, at the price of owning the extraction pipeline. In every case, the storage is only reclaimed when you delete the source records from CRM.

---

Staring at a storage overage and a pile of records nobody will let you delete? Talk to us — designing the retention policy, picking the right archive destination, and wiring the archive-and-delete so it’s safe and reversible is exactly the work we do.