Salesforce Large Data Volume: Moving 10+ TB Without Hitting the Wall

Large data volume is the point where Salesforce stops behaving like a database with a friendly UI and starts behaving like a system with hard physics. Queries that were instant time out. Loads that were fast deadlock. Reports that ran fine crawl. "LDV" is not a number; it is the moment the defaults stop working and you have to design for the data instead of against it. Here is where the walls are, and how to get 10+ TB through them.

The first wall: selective queries

At volume, an unselective query is the enemy. A filter that matches too large a share of a huge table forces a full scan, and a full scan on tens of millions of rows times out. The fix is selectivity: filter on indexed fields, keep filters narrow enough that the optimizer can use an index, and know which standard fields are indexed and which of your custom fields need to be. Most LDV performance problems trace back to a query that was never selective in the first place.

Skinny tables and indexes

When the right fields are indexed and queries are still slow because they span standard and custom fields, Salesforce can provision a skinny table: a behind-the-scenes copy of the most-used fields that avoids the join between the base table and the custom-field table. You do not build these yourself; you work with Salesforce to put them where the read patterns justify them. The point is architectural: at LDV, you design the read path deliberately rather than hoping the optimizer figures it out.

Partitioning, archiving, and not storing what you do not need

The cheapest large query is the one you never run because the data is not there. A real LDV strategy includes archiving: moving cold records out of the operational org into storage where they stay retrievable but stop weighing on every query, index, and backup. Ten terabytes that has to stay hot is a very different problem from ten terabytes where two are hot and eight are archived. Deciding which is which, by record age, object, and legal-hold requirement, is often the highest-leverage move in the whole engagement.

Moving it: Bulk API 2.0 with the volume patterns

Actually moving LDV in or out uses the Bulk API 2.0 patterns: asynchronous jobs, PK chunking for extraction so no single query has to carry the whole object, and careful ordering so parallel batches do not deadlock on shared parents. Partitioning the work by object and by ID range keeps each slice bounded and lets a run resume from a checkpoint instead of restarting from zero when something fails at hour six. At 10+ TB, "restart from zero" is not an option, so checkpoint and resume is not a nice-to-have; it is the design.

Data residency at scale

Enterprise LDV often carries a second constraint: regulated data that has to stay in a region. Moving it then is not just a volume problem but a jurisdiction problem, handled with localized infrastructure and policy so EU or APAC data does not transit somewhere it is not allowed to be. At scale, residency and volume have to be designed together, not bolted on afterward.

The honest note

LDV is not a feature you turn on. It is a discipline: selective queries, deliberate indexing, skinny tables where the reads justify them, an archiving strategy that keeps the hot set small, and move patterns built to checkpoint and resume. The teams that hit the wall are the ones that treated 10 TB like 10 GB and found out at the worst possible moment. The teams that get through are the ones that designed for the physics from day one. If you are staring at a large data volume move, tell me the shape of it and I will tell you where the walls are before you hit them.