Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Short answer: Data Loader is a client, Bulk API 2.0 is what it can talk to. So the real question is not “which one” but “which API should this load use”, and the answer is volume: under about 50,000 records the REST or SOAP path is usually faster end to end, and above that Bulk API 2.0 is the only sensible choice.

Choosing how to load dataData Loader is a client and Bulk API is what it can talk to, so the real question is which API.What kind of load is this?Under 10,000 records, one-offData Loader without Bulk API,or the CLI. Synchronousresults, errors on screen, nojob to monitor.A migration, tens ofthousands upwardBulk API 2.0, file sorted byparent Id, objects loadedparents-first. The sort iswhat prevents row lockerrors.Recurring and scheduledNot an interactive client.CLI, command-line interface,or a real integration. Aloader on someone's laptop isa single point of failure.Bulk API processes batches in parallel. Two batches touching the same parent collide and one getsUNABLE_TO_LOCK_ROW. Sort the file by parent Id before you load it.
Three kinds of load, and the tool each one actually needs.

Why “Data Loader vs Bulk API” is the wrong framing

Data Loader has a checkbox marked “Use Bulk API”. Ticking it changes which API the same client calls. So a comparison between the tool and the API is really a comparison between the tool’s two modes, plus whatever else you might use — the CLI, a middleware platform, or your own script.

What actually differs between the APIs:

  • Serial vs parallel. Bulk API splits your file into batches and processes them in parallel across servers. That is the speed, and it is also the cause of the row lock errors that only appear at scale.
  • Asynchronous. You submit a job and poll for the result. Nothing is finished when the upload finishes, and the errors arrive later, in a separate file.
  • Limits. Bulk API 2.0 has a daily record ceiling separate from your API call allowance. The REST path consumes API calls at roughly one per batch of 200.

Where the parallel processing bites

Two batches processed at the same time, both containing children of the same parent account, both trying to lock that account. One wins and one gets UNABLE_TO_LOCK_ROW. The fix is to sort the file by the parent ID before loading, so that records sharing a parent land in the same batch. This is the single most useful thing to know about bulk loading and it is a property of your file, not a setting.

The other lever is serial mode. Bulk API can be told to process batches one at a time, which removes the contention and most of the speed. Reach for it when sorting is not enough, usually on a heavily skewed object as described in ownership and account data skew.

Choosing by what the load actually is

Under 10,000 records, one-off. Data Loader without Bulk API, or the CLI. You get synchronous results, errors on screen, and no job to monitor.

10,000 to a few million, a migration. Bulk API 2.0, file sorted by parent, loaded in object order so parents exist before children. That order is the subject of getting the object order right.

Recurring, scheduled. Not Data Loader’s interactive mode. Either the command-line interface, the CLI’s data commands, or a proper integration. A migration tool running on someone’s laptop on the first of the month is a documented single point of failure.

Anything needing a transformation. Neither. Transform before the file reaches the loader, in whatever produces the file. Every attempt to make the loader do it ends in a mapping file nobody understands.

Settings that change the outcome

  • Turn off automation you do not need. Validation rules, flows and triggers all run. A load that takes six hours often takes twenty minutes with one flow deactivated, and the decision to deactivate it is a real risk that needs to be recorded.
  • Batch size. Smaller batches mean more overhead and fewer lock collisions. Start at 200 and reduce if you see locks, rather than starting low by default.
  • Assignment rules and workflow. The client has headers for these. They default off in some tools and on in others, and the difference is whether ten thousand leads get assigned.
  • Hard delete. Available, permanent, skips the recycle bin. Useful for a failed load, dangerous for everything else.

Always keep the success file

The success file contains the new IDs mapped to your source keys. Without it, a failed second load cannot be reconciled against the first, and you are matching on name. Keep both files, named by date and object, somewhere that is not the loading machine.

Frequently asked

Is Bulk API 2.0 different from Bulk API 1.0? Yes. Version 2 manages batching for you — you send the whole file and it decides. Version 1 made you create batches yourself. New work should use 2.0.

Why did my load partially succeed? Each batch commits independently. There is no transaction across the job, so a mid-file failure leaves earlier records inserted. Plan the rollback before the load, not after.

Can I upsert with Bulk API? Yes, on an external ID field, and it is the right way to make a load re-runnable. See upsert with external IDs.