Batch size is the number of records Data Loader (or any other Salesforce client) packs into a single API call. If you have 50,000 rows in your CSV and a batch size of 200, Data Loader sends 250 API calls, each carrying 200 rows.
Why batching at all?
The Salesforce API isn’t built for one-record-at-a-time chatter — every HTTP request has overhead (auth check, parsing, transaction setup). Batching amortises that cost. It also matches how Salesforce internally processes work: every trigger, flow, and rollup is bulk-aware, expecting a collection of records.
Why not just send the whole file?
Two limits hit you fast:
- HTTP request size — there’s a payload ceiling per call.
- Per-transaction governor limits — every batch executes as one Apex transaction, so all triggers/flows for that batch must collectively stay within 10,000 DML rows, 100 SOQL queries, 10 minutes CPU on Bulk API, etc.
A 5,000-record batch with a chatty trigger will burn the SOQL budget. A 200-record batch usually fits comfortably even with moderately complex automation.
The batch boundaries by API
| API | Default batch | Max batch | Use case |
|---|---|---|---|
| SOAP API | 200 | 200 | Small / medium loads, default Data Loader |
| Bulk API | 2,000 | 10,000 | Large loads, async |
| Bulk API 2.0 | Managed by Salesforce | n/a (server-side chunking) | Modern integrations |
Picking a batch size
Three questions decide it:
- How much automation fires per record? Light → bigger batches. Heavy triggers/flows → smaller.
- Is there lock contention? Multiple batches updating the same parent (e.g. Opportunities under one Account) cause
UNABLE_TO_LOCK_ROW. Smaller batches and/or serial mode help. - How much do you care about partial success? Each batch commits or rolls back as a unit. Smaller batches = fewer rows lost per failure.
A pragmatic table
| Scenario | Recommended batch |
|---|---|
| Bulk Insert with no triggers | 10,000 (Bulk API) |
| Update with light field changes | 200 (SOAP) or 2,000 (Bulk) |
| Update with trigger + flow chain | 50–100 |
| Inserts under master-detail rollups | 100–200 |
| Deep approval / flow automation | 1–25 |
What batch size is NOT
- Not the total job size. A 1-million-row file with batch size 200 still loads 1 million rows; it just sends 5,000 batches.
- Not the same as the file split. You can split the source file separately for organisational reasons; batch size is the API-level chunk.
- Not the same as the parallelism. Bulk API runs batches in parallel by default; “batch size” governs the size, “serial mode” governs the parallelism.
Quick interview line
“Batch size is how many records go in one API call. Default is 200 for SOAP API, up to 10,000 for Bulk API. Smaller batches reduce governor-limit and lock-contention risk at the cost of more round-trips.” That covers everything an interviewer wants in two sentences.
Verified against: Data Loader Guide — Configuring, Bulk API Developer Guide, Metadata API Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.