Salesforce ELT: Extract, Load & Transform Salesforce Data

What is Salesforce ELT?

Salesforce ELT is the process of pulling data out of Salesforce (Extract), writing it into a destination in something close to its raw form (Load), and only then reshaping it into its final structure (Transform) using the compute power of the destination system itself, rather than a separate transformation engine sitting in between.

That’s the opposite order from traditional ETL, where transformation happens before the data ever lands. The shift exists because modern cloud warehouses Snowflake, BigQuery, Databricks, Synapse are cheap enough and fast enough to run heavy transformations directly on raw data at scale. Instead of building transformation logic into the pipeline itself, ELT pushes that work downstream, usually through SQL models (often managed with a tool like dbt) that run inside the warehouse.

For Salesforce specifically, this means: get the data out and landed as fast and reliably as possible, keep the raw copy intact for auditability, and let analysts or data engineers build transformation logic in the warehouse where it’s easier to iterate, version, and test.

Why teams move Salesforce pipelines to ELT

A few reasons this pattern has become the default for data teams with any warehouse maturity:

• Raw data is preserved. If a transformation has a bug, you can rebuild it from the raw landed data instead of re-extracting from Salesforce and hitting API limits again.
• Transformation logic lives in one place. SQL models in the warehouse are easier to version-control, test, and review than logic buried inside an integration tool’s configuration.
• Warehouse compute scales independently. A slow transformation doesn’t bottleneck the extraction pipeline, and vice versa you can throw more warehouse compute at a transformation without touching the ingestion layer at all.
• Schema drift is easier to recover from. A new Salesforce field just shows up as a new raw column; nothing breaks until someone chooses to incorporate it into a transformation model.

Extract: landing Salesforce data with minimal friction

The extraction step in ELT doesn’t change much from ETL you still need to get data out of Salesforce efficiently and incrementally. What changes is the goal: extract cleanly enough to land reliably, without trying to solve every data-quality problem before it even reaches the warehouse.

• Bulk API 2.0 for high-volume objects, processed asynchronously in batches
• SOQL with incremental filters typically LastModifiedDate so each run only pulls changed records rather than re-querying the whole object
• A separate check for deletions, since Salesforce’s deleted-records endpoint isn’t covered by a LastModifiedDate filter alone

Salesforce’s daily API call limits still apply regardless of which side of ETL/ELT you’re on. Incremental extraction isn’t optional at scale it’s the difference between a pipeline that runs quietly every day and one that stops working mid-month because it burned through the org’s API allocation re-pulling data that hadn’t changed.

Load: getting raw Salesforce data into the warehouse fast

In ELT, the load step is deliberately unglamorous the goal is to land data as close to its source shape as possible, not to reshape it on the way in.

• Land raw, load fast. Minimal transformation at load time means fewer places for something to silently go wrong before the data is even queryable.
• Preserve source structure. Object and field names, picklist values, and relationships stay close to how Salesforce represents them, so the raw layer stays a trustworthy source of truth.
• Use upsert logic keyed on a stable ID, so incremental loads update existing rows instead of duplicating them.
• Load in dependency order where the warehouse schema still needs it though ELT is more tolerant of loading objects independently, since transformation (not load) is where relationships typically get resolved.
• Keep a full history where it matters. Some ELT designs load Salesforce data as an append-only log (every version of every record) rather than overwriting in place, which lets transformations reconstruct historical states later.

Transform: where the real modeling happens, after load

This is where ELT diverges most from ETL. Instead of reshaping data in the pipeline itself, transformation happens in SQL (or a transformation framework like dbt) running directly against the raw, landed Salesforce tables in the warehouse.

Typical transformation work at this stage:

Field and type cleanup. Converting Salesforce’s raw field representations multi-currency values, org time zone dates, picklist codes into the types and formats analytics or downstream systems expect.

Deduplication. Landing raw data doesn’t fix duplicate Accounts or Contacts accumulated over years of manual entry; that logic runs as a transformation model against the raw layer.

Business logic and joins. Combining Opportunity, Account, and custom object data into the flattened or star-schema tables that BI tools actually query, with business rules (like how “qualified pipeline” is defined) encoded explicitly and version-controlled.

Incremental transformation models. Just as extraction should be incremental, transformation models in mature ELT setups process only new or changed raw records rather than reprocessing the entire raw table on every run.

Because this logic lives in the warehouse as SQL rather than inside an integration tool’s configuration, it’s straightforward to test, review in a pull request, and roll back if a model introduces a regression.

ELT vs. ETL vs. replication for Salesforce

ETL transforms data before it lands in the destination useful when the destination has no compute of its own to lean on, or when only a lightweight, fixed transformation is needed.

ELT lands raw data first and transforms afterward, using the destination’s own compute the more common pattern now that cloud warehouses can absorb that workload cheaply.

Replication sits underneath both it’s the extraction and load mechanism that keeps a copy of Salesforce data current in the destination. Whether that raw copy then gets transformed before or after loading is really the ETL-vs-ELT distinction; the extraction and load layer itself is largely the same either way.

On CDC: this doesn’t change with ELT. Salesforce doesn’t expose transaction logs the way a database does, so extraction whether feeding an ETL or ELT pipeline still runs through the Salesforce API layer. DBSync Cloud Replication extracts and loads Salesforce data via scheduled, incremental SOQL-based polling, not log-based Change Data Capture. CDC is something DBSync applies specifically to database-to-database replication, where the source system exposes transaction logs to read directly. If a vendor claims real-time CDC for Salesforce specifically, what’s usually running underneath is either Salesforce’s own separately licensed Platform Events/CDC feature, or scheduled polling on a short interval.

Common failure points in Salesforce ELT pipelines

• Treating the raw layer as disposable instead of an audit trail once it’s overwritten without history, you lose the ability to rebuild a broken transformation
• Transformation models with no incremental logic, reprocessing the entire raw table every run as data volume grows past what that’s sustainable for
• No ownership boundary between raw and transformed layers, so analysts start querying raw Salesforce tables directly and building reports on unstable, unvalidated data
• Ignoring API limits on the extraction side because “the transformation happens later anyway” extraction efficiency still matters regardless of where transformation runs
• Undocumented business logic buried in a transformation model that only one person understands

Building a Salesforce ELT pipeline: a practical checklist

1. Scope the Salesforce objects to extract raw storage is cheap, but unscoped extraction still costs API calls and clutters the raw layer
2. Extract incrementally via SOQL or Bulk API 2.0, with a separate check for deleted records
3. Load into the warehouse in as close to raw form as possible, using upsert or append-only history depending on whether you need to reconstruct past states
4. Build transformation models (SQL or dbt) against the raw layer don’t let analysts query raw tables directly for reporting
5. Make transformation models incremental once raw volume grows past a trivial size
6. Version-control transformation logic and review changes the way you’d review application code
7. Monitor both layers separately: extraction/load failures and transformation model failures are different problems with different fixes
8. Re-test extraction against sandbox previews of Salesforce’s three annual releases, since field and object changes surface in the raw layer first

Frequently asked questions

What’s the difference between Salesforce ETL and Salesforce ELT? ETL transforms Salesforce data before loading it into the destination. ELT loads data in something close to raw form first, then transforms it afterward using the destination’s own compute typically a cloud warehouse running SQL models.

Does DBSync support CDC for Salesforce in an ELT pipeline? No. Whether feeding an ETL or ELT pipeline, DBSync Cloud Replication extracts Salesforce data through scheduled, incremental SOQL-based polling rather than log-based Change Data Capture. CDC is available for database-to-database replication, where the source exposes transaction logs directly.

Why keep a raw layer if I’m going to transform the data anyway? The raw layer is your recovery path. If a transformation model has a bug, you rebuild from the raw data already sitting in the warehouse instead of re-extracting from Salesforce and burning through API limits again.

Do I still need incremental extraction with ELT, since transformation happens later? Yes. Salesforce’s API limits apply at extraction time regardless of when transformation happens. Pulling entire objects on every run instead of filtering incrementally still risks hitting the daily API cap.

What tool actually does the transformation step in Salesforce ELT? Usually a SQL-based transformation framework running inside the warehouse dbt is the most common choice rather than the same tool that handled extraction and load. Keeping these separate is part of what makes ELT easier to maintain than embedding transformation logic in the pipeline itself.

The bottom line

Salesforce ELT doesn’t change how data comes out of Salesforce extraction still runs through the API layer, still needs incremental filtering, and still has nothing to do with log-based CDC. What changes is where the reshaping happens: after loading, in the warehouse, where it’s version-controlled, testable, and recoverable if something goes wrong. For teams with a real warehouse behind them, that trade-off is usually worth it.