Sync data from
Amazon Redshift to Salesforce

We've outlined the 5 most common options you have to sync your Redshift data to Salesforce. Using one of these options will allow your organization to move from only your data team having access to view and use data to having unblocked marketing and business teams.

Option 1: Reverse ETL (Hightouch)

Reverse ETL is often thought of as the solution to this last-mile-analytics problem. Reverse ETL tools like Hightouch run on top of Redshift and don’t actually ever store any of your data. With Hightouch all you have to do is define your data in Redshift using SQL or your own existing data models.

With Hightouch's native integrations, you can sync your data in Redshift directly to Salesforce giving you access to real-time data. You can even map your columns to any custom object, enabling you to focus on even more business outcomes. You can actually test this out yourself by following these steps.

Step 1: Connect to Your Data Source

Step 2: Connect Hightouch to your destination

Step 3: Create a data model or leverage an existing one

You can use SQL to define your data directly in the Hightouch UI or even leverage your existing data models.

Step 4: Choose Your Primary Key

With Hightouch you can map on any unique key, not just users and accounts.

Step 5: Create Your Sync

Once you have created your sync, you simply have to choose the appropriate columns and map them to the fields in your end destination.

Step 6: Schedule Your Sync

Once your sync is created you can run it manually, define a set interval, or schedule it to run after a dbt job is completed.

The first integration with Hightouch is completely free so you can actually get started today. If you want to learn more about Reverse ETL, download our guide.

Option 2: Manual CSV Files

Downloading and uploading CSV files is one of the easiest ways to move data from Redshift to Salesforce. Doing this is not the most efficient use of your time though because it's not a one-time event. Every time sales or marketing asks you for a specific data set you have to manually download it.

In addition to this, data stored in a CSV file becomes stale really quickly. Ideally want to have a continuous flow between Redshift and Salesforce so you don’t have to worry about whether or not your business teams have access to the data they need to do their jobs.

Option 3: Custom Integrations

Building an in-house data pipeline directly to Salesforce is another way to go about moving your data from Redshift to Salesforce, but this can be challenging to do as Salesforce and Redshift's APIs are constantly changing, which means you have to check for upstream or downstream changes on a regular basis to ensure your data is flowing properly.

Additionally building and maintaining your own data pipeline is not only time-consuming, but it's also extremely resource-intensive, and depending on the scale of data that you are trying to move it becomes even more challenging.

Option 4: iPaaS (Integration Platform as a Service)

Integration platforms like Tray or Workato let you build intuitive workflows to move data from one system to another, but these solutions are really designed to automate tasks and improve efficiency.

If your use case is simple solutions like this can be a great option, but as soon as any complexity gets thrown into the mix, you will find yourself buried in complex if/then statements with multiple dependencies in each individual step. Managing these workflows can be equally as challenging as maintaining your own in-house data pipeline.

Option 5: CDPs (Customer Data Platform)

For many years, CDPs have been the go-to solution to tackle the problem of democratizing the data that exists in your warehouse because they consolidate all of your customer data into another centralized platform. The problem is, CDPs don’t mesh with your existing technology stack because they create a second source of truth.

CDPs also own your data because it is no longer stored in your cloud environment. This can make things difficult from a compliance standpoint. Time-to-value is also not immediate because CDPs can easily take over a year to implement. They are also extremely rigid when it comes to object mappings. You can only map columns to objects like users and accounts. In reality, your business is usually much more complex.