Salesforce to Amazon Redshift: How to Move Your Data
Move Salesforce into Amazon Redshift with Airbyte. Why a successful sync can be incomplete, when that self-corrects, and why formula edits never re-read.
Moving Salesforce into Amazon Redshift puts CRM data where it can be joined to everything that explains it. Salesforce knows what was sold and by whom, and nothing about product usage, support cost or what those customers were worth after the deal closed.
One behaviour deserves attention before anything else, because it is the most consequential quiet failure in this pipeline. When Salesforce's daily API limit is reached, the sync stops early and reports success, and whether that corrects itself depends entirely on a setting you chose.
Salesforce to Amazon Redshift at a glance:
Why move data from Salesforce to Amazon Redshift?
Two situations account for most of these pipelines.
The first is joining. Whether a segment is profitable after support cost, or whether marketing sourced pipeline converts, needs CRM records next to data Salesforce has never seen. A warehouse is where those meet and where contested definitions get settled once.
The second is reporting without consuming Salesforce capacity. Complex reports against the platform compete with the people using it to work, and a warehouse copy answers those questions without anyone touching the system of record.
What do you need before you start?
One of these is a permissions decision that quietly defines your dataset:
A Salesforce user whose visibility matches what you need. The connector replicates only the objects and fields that user can see, so a restricted account produces a quietly incomplete warehouse. Create a dedicated integration user with deliberate access. The Salesforce source documentation covers the setup.
An understanding of your daily API allowance. It depends on your edition and user count, and it is shared with every other integration touching the org. Find out what else consumes it before choosing a schedule, because exceeding it fails quietly.
An S3 staging bucket and IAM permissions. The Redshift destination writes data to S3 as files with a manifest, then issues a COPY command, which is Redshift's own recommended approach. You need put, get, delete and list on the bucket, in the same region as the cluster.
A lookback window and Redshift entities. The default is ten minutes, covering Salesforce's eventual consistency. On the warehouse side you need a database, a schema and a user able to write data and manage staging operations.
Note also that an SSH tunnel covers the SQL connection only. Staging traffic reaches S3 over HTTPS regardless, so a network design assuming everything passes through a bastion is wrong.
How do you build a Salesforce to Amazon Redshift pipeline in Airbyte?
Step 1: Create the integration user deliberately
Work with your Salesforce administrator to create a user whose profile sees exactly the objects and fields your warehouse needs. Borrowing somebody's personal login means your dataset is scoped to their role, which changes when they move teams and which nobody will think to check.
Step 2: Configure the Salesforce source
Click Sources in the left navigation, then New Source, and select Salesforce, following adding a source. Authenticate as the integration user, set a start date, and indicate whether this is a sandbox, since production and sandbox orgs use different endpoints.
Step 3: Configure the Redshift destination
Click Destinations, then New Destination, and select Redshift, following adding a destination. Supply the cluster host, database, schema and credentials, along with your S3 bucket and IAM key. Staging files are removed after a successful COPY by default, and can be retained if you need them for debugging.
Step 4: Use incremental wherever you can
Click Connections, then New connection, select your objects and choose an incremental sync mode wherever the object supports it. That is not a performance preference on this source, it is what makes an interrupted sync recoverable, as the section below explains.
Set sort keys on close dates and created dates too, since CRM reporting is almost always filtered by period and grouped by owner.
Why does a successful sync sometimes contain less than it should?
Because of how the connector handles Salesforce's daily API limit. When the limit is reached mid-sync, the run ends early and is reported as successful, then resumes on the next scheduled run. Nothing in your monitoring distinguishes that from a complete sync.
On incremental streams that behaviour is self-correcting, because the next run picks up from where the cursor stopped and the gap closes on its own. The design is sensible, and the only cost is that your warehouse is briefly behind without saying so.
On full refresh streams it is not self-correcting at all. Each run starts from the beginning, so a stream that cannot finish within your allowance never finishes, and it reports success every time it fails. That is why incremental is a correctness decision here rather than a performance one.
Why do formula field changes never appear?
Because editing a formula field's definition does not change the modification timestamp on the records it affects. Salesforce recalculates the values, but as far as incremental sync is concerned nothing happened, so the connector never re-reads those records.
The result is a warehouse holding values computed under the old formula indefinitely, while Salesforce shows the new ones. Both systems look right in isolation and disagree with each other, which is a confusing thing to debug if you did not know this could happen.
The fix is a stream reset after any formula change, which forces a full re-read. So ask your Salesforce administrator to tell you when formula fields change, and treat that as a pipeline event rather than a configuration detail that stays inside their team.
Frequently asked questions
My sync says success but data is missing. Why?
The daily API limit was probably reached, which ends the sync early and reports success. Incremental streams resume next run; full refresh streams restart from the beginning and may never complete.
Why do my formula field values disagree with Salesforce?
Editing a formula does not change record timestamps, so incremental never re-reads them. Reset the stream after any formula change.
Why are some objects missing entirely?
The connector sees only what the authenticating user sees. Check that user's profile and field-level security rather than the connector configuration.
Do I need an S3 bucket to load into Redshift?
Yes. The destination stages data in S3 and loads it with COPY, which is Redshift's recommended approach. Put the bucket in the same region as your cluster.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. You will want Redshift views resolving owner and record type identifiers and defining your pipeline metrics.
Get your Salesforce data into Amazon Redshift
Use incremental wherever the object supports it, because on this source that is a correctness decision rather than a performance one. Scope the integration user deliberately, provision the staging bucket in your cluster's region, and treat formula field changes as a pipeline event needing a stream reset.
Airbyte's connector catalog includes 700+ pre-built connectors, so CRM data can sit beside the product and billing sources that explain it. For the same source in another warehouse, see Salesforce to Snowflake, and for another CRM landing in Redshift, HubSpot to Amazon Redshift.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.