Redshift ETL tools compared: the best AWS Redshift ETL pipeline and zero-ETL software
Twelve ways to get data into Amazon Redshift, lined up by how each one runs, what it connects to, how it bills and who it is wrong for. Read the zero-ETL section before you shop: for Aurora, RDS, DynamoDB and several SaaS applications, AWS now replicates into Redshift with no pipeline at all, which makes a large share of published comparisons of this category out of date. Every number below was read from AWS documentation on 16 August 2026.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
AWS documentation read 16 August 2026 · Last updated August 2026
Which Redshift ETL tool should you use?
Start by checking whether you need a tool at all. If the source is Aurora, RDS for MySQL, DynamoDB, Salesforce, SAP, ServiceNow or Zendesk, a zero-ETL integration replicates it into Redshift with no pipeline to build or operate, and no connector vendor to pay. If the source is outside that list, pick by what you are short of: Fivetran if you want managed breadth and will accept a metered bill, Airbyte if you want the largest catalog and control over where it runs, AWS Glue if you have Spark skills and want the job inside AWS, DMS for continuous replication from databases with no zero-ETL path. And if the requirement is a handful of dependable scheduled syncs with field mapping an analyst can edit and a bill that does not move, Adapters is flat at $49 to $399 a month.
The correction worth making early: zero-ETL is not a marketing label for a faster connector. It is a genuinely different arrangement in which AWS owns the replication and you give up in-flight transformation, write access to the destination database, and any table that lacks a primary key. That trade is excellent for some teams and disqualifying for others, so the constraints table below matters more than any feature list. For the broader category outside Redshift specifically, start with best data integration tools.
Redshift ETL tools compared
Billing units rather than price tags, because almost everything in this category is volume-metered or consumption-based. The one flat published figure below is ours. Verify current numbers with each vendor before you sign anything.
| Tool | Where it runs | Approach | Connects to | Pricing model | Best for |
|---|---|---|---|---|---|
| Zero-ETL integrations | Native inside AWS, no pipeline to operate | Managed replication, no transformations in flight | Aurora MySQL and PostgreSQL, RDS for MySQL, DynamoDB, plus Salesforce, SAP, ServiceNow and Zendesk | No separate integration fee. You pay Redshift storage and compute | AWS-native sources where you want replication without owning a pipeline |
| AWS Glue | Serverless inside AWS | Spark-based ETL, code-first with a visual option | S3, JDBC databases, a crawler-driven catalog and marketplace connectors | Per data processing unit hour | AWS shops with Spark skills that need real transformation logic |
| AWS DMS | Managed inside AWS | Full load plus ongoing change data capture | Most relational databases, on-premises or in AWS | Per replication instance hour plus storage | Continuous database replication into Redshift, including from outside AWS |
| Amazon Data Firehose | Serverless inside AWS | Streaming delivery, buffers events and loads them | Application events, Kinesis streams, logs and telemetry | Per gigabyte ingested | Event streams that should land continuously rather than on a schedule |
| Fivetran | Managed cloud | Automated ELT with schema drift handling | The largest managed connector catalog, plus database CDC | Monthly active rows for connections, model runs for transformations | Teams that want zero pipeline maintenance and will pay a metered bill for it |
| Airbyte | Open source self-hosted, or Airbyte Cloud | ELT, with a connector development kit for anything missing | Very large catalog, community and certified connectors | Free self-hosted, or Cloud billed by credits tied to rows and volume | Engineering teams that want catalog breadth and control over where it runs |
| Matillion | Managed cloud, transformations pushed down into Redshift | Visual ELT built for cloud warehouses | Connectors plus a graphical transformation layer | Credit-based consumption | Teams that want transformation logic in a canvas rather than in SQL files |
| Hevo Data | Managed cloud | No-code ELT with in-flight transformations | SaaS applications and databases | Tiered by events loaded per month | Analytics teams without a data engineer on staff |
| Stitch | Managed cloud, part of Talend and now Qlik | Simple ELT built on the Singer standard | A steady mid-sized catalog | Tiered by rows replicated per month | Straightforward replication where simplicity beats features |
| Informatica | Managed cloud, enterprise deployment options | Full ETL and ELT with governance, quality and lineage | Very broad, including mainframe and legacy systems | Consumption units across the platform | Regulated enterprises buying governance as much as movement |
| dbt | Open source Core, or dbt Cloud | Transformation only. It does not move data | None. It models what is already in Redshift | Free Core, or seat-based Cloud | The T in ELT, paired with any of the loaders above |
| Adapters | Managed cloud, scheduled sync | Visual field mapping and no-code transforms, both directions | Postgres, MySQL, SQL Server, Snowflake, BigQuery, Salesforce, HubSpot, NetSuite, Stripe, Shopify, QuickBooks, Xero and more | Flat monthly price: $49, $149, $399, or Enterprise | Ops and finance teams that want a predictable bill and mappings an analyst can edit |
The column a table cannot show you is connector depth. Two vendors will both list Salesforce and only one will replicate the custom object with the formula field you actually report on. During the trial, sync the exact tables you need and read what landed, rather than trusting the logo on the connector page.
The six native ways to get data into Redshift
Every tool in the comparison above is ultimately driving one of these. Knowing which one your vendor uses tells you more about latency and cost than any feature list. Details below were read from AWS documentation on 16 August 2026.
| Method | Shape | Latency | Use it for | The catch |
|---|---|---|---|---|
| COPY from Amazon S3 | Bulk parallel load from files in a bucket | Whenever you schedule it | Nightly batch loads, historical backfills, migrations | Redshift auto-splits uncompressed CSV and columnar files of 128 MB or larger. Formats it cannot split load serially, which is much slower |
| Zero-ETL integration | Managed replication with no pipeline | Near real time, 15 minutes minimum for DynamoDB, 1 hour for application sources | Aurora, RDS, DynamoDB, Salesforce, SAP, ServiceNow and Zendesk | The destination database is read only, source tables need a primary key, and no transformations happen in flight |
| AWS DMS | Full load followed by change data capture | Continuous | Databases with no zero-ETL path, including on-premises sources | You size and pay for a replication instance, and it is one more thing to monitor |
| Amazon Data Firehose | Buffered streaming delivery | Continuous, buffered | Event and log streams | Buffer settings decide the real freshness, and it is delivery only, not transformation |
| Redshift Spectrum | Query files in S3 without loading them | Live at query time | Cold history you query occasionally and do not want to store in the cluster | You pay per query scan and performance depends on the file layout in S3 |
| INSERT and staging tables | SQL writes from your own code | Immediate | Small reference tables and the MERGE step after a COPY into staging | Row-by-row INSERT is the classic Redshift performance mistake. Use COPY for anything of size |
File layout is the lever most teams never touch and it is worth more than a cluster resize. Redshift automatically splits uncompressed CSV and columnar files of 128 MB or larger, but a GZIP-compressed CSV cannot be split, so one large file loads serially across a single slice while the rest of the cluster sits idle. If loads are slow, count the files before you add nodes. The mechanics of the zero-ETL path specifically are in our guide to Redshift zero-ETL.
Zero-ETL requirements and limits, in one table
Zero-ETL removes the pipeline, and in exchange it imposes constraints that decide up front whether it can work for you. These are the ones that actually stop projects, taken from the AWS considerations page on 16 August 2026.
| Rule | What AWS requires | Why it matters |
|---|---|---|
| Target warehouse | Redshift Serverless, or a provisioned cluster of an RA3 or RG node type | Older node types cannot be a zero-ETL target at all |
| Encryption and case sensitivity | A provisioned cluster must be encrypted, and case sensitivity must be enabled | Both are prerequisites, so an existing warehouse may need changing first |
| Primary keys | Tables in the source must have a primary key or they cannot be replicated | This is the most common reason a table silently never appears in Redshift |
| Read-only destination | You cannot create tables, views or materialized views in the destination database | Model into a separate database and query across, rather than writing into the replica |
| No transformations | Data is replicated as-is. Transformations happen afterwards, inside Redshift | If you need masking before landing, zero-ETL is the wrong mechanism |
| Integration limit | 50 zero-ETL integrations per Redshift warehouse target | Aurora PostgreSQL sources are additionally capped at 100 databases |
| VARCHAR ceiling | Redshift VARCHAR maxes at 65,535 bytes. Oversized content fails the table | Set TRUNCATECOLUMNS to TRUE to truncate instead of failing replication |
| Character encoding | Redshift accepts only UTF-8 and might not honor the source collation | Sorting and comparison can differ, which changes query results |
The primary key rule is the one that catches people. A table without one is not replicated, and the failure is quiet: everything else arrives and that table simply never appears. Audit the source schema for tables lacking a primary key before you promise anyone a delivery date.
The Redshift numbers worth knowing before you load
Six dated facts, each read from AWS primary documentation on 16 August 2026.
50
Zero-ETL integrations per Redshift warehouse
The documented ceiling for a single target data warehouse. Aurora PostgreSQL sources carry a separate maximum of 100 replicated databases. Source: AWS zero-ETL considerations.
128 MB
The Redshift automatic file split threshold
Redshift automatically splits uncompressed CSV and columnar Parquet or ORC files of 128 MB or larger. Columnar files smaller than that are not split. Source: AWS loading data best practices.
1 MB to 1 GB
Recommended size for files you split yourself
For formats Redshift cannot auto-split, such as GZIP-compressed CSV or JSON, AWS recommends similarly sized files in that range, and making the file count a multiple of the number of slices in the cluster.
15 min
Minimum zero-ETL latency from DynamoDB
Application sources such as Salesforce, SAP, ServiceNow and Zendesk have a minimum latency of 1 hour instead. REFRESH_INTERVAL lets you make either slower, never faster.
65,535 bytes
Maximum Redshift VARCHAR length
If replicated content does not fit, replication stops and the table enters a failed state. Setting TRUNCATECOLUMNS to TRUE truncates the value instead. Source: AWS zero-ETL considerations.
$49/mo
Adapters entry price, flat
No monthly active rows, no credits, no per-connector charge. The bill is the same whether the sync moves 400 rows or 400,000.
How a Redshift pipeline should be built, step by step
Five decisions that decide whether the pipeline is boring or a recurring incident. The tool you pick affects how much of this it does for you, but none of them do all five.
Step 01 / Check
Find out whether zero-ETL covers your source first
This is the cheapest question on the list and almost nobody asks it before shopping. If the data lives in Aurora MySQL or PostgreSQL, RDS for MySQL, DynamoDB, Salesforce, SAP, ServiceNow or Zendesk, AWS will replicate it into Redshift with no pipeline for you to build, operate or pay a vendor for. Confirm the prerequisites, which are a Serverless or RA3 target, encryption, case sensitivity enabled, and a primary key on every table you want replicated. If all of that holds, buying a connector for the same job is spending money on a problem AWS already solved.
Step 02 / Land
Use COPY, and never a loop of INSERT statements
Redshift is a columnar MPP database, and its load performance comes from reading many files in parallel across the cluster slices. COPY from S3 does that. A loop of single-row INSERT statements defeats the entire architecture and is the most reliable way to make a Redshift cluster look slow. Land raw data in a staging table with COPY, then MERGE it into the target table in SQL.
Step 03 / Split
Get the file layout right before you resize the cluster
Redshift automatically splits uncompressed CSV and columnar files of 128 MB or larger. Anything it cannot split, including GZIP-compressed CSV and JSON, loads serially unless you split it yourself. AWS recommends files of similar size between 1 MB and 1 GB after compression, with the file count a multiple of the number of slices. If loads are slow, count your files before you add nodes.
Step 04 / Type
Decide the column types before the first load, not after
Redshift VARCHAR maxes at 65,535 bytes, and content that does not fit fails the table rather than warning you. Redshift accepts only UTF-8 and may not honor the collation your source used, which changes sorting and comparison. Numeric scale is worth checking too: a default decimal scale that is shorter than the source silently truncates. Every one of these is cheap to set on day one and expensive once dashboards depend on the column.
Step 05 / Watch
Alert on the table that stopped syncing, not just on errors
Zero-ETL tables sit in states, and by default you can only query the ones in the Synced state. A table that failed on an oversized value, or an integration that dropped into a failed state after a source was deleted, does not announce itself in a dashboard that keeps rendering yesterday numbers. Check SVV_INTEGRATION_TABLE_STATE, and route a real alert to a human who is on duty.
Step four is where the silent damage happens, and data mapping best practices covers the type and naming decisions in detail. If you have not settled the incremental strategy, change data capture tools compares log-based options against watermark polling, and ETL versus ELT explains why landing raw and transforming in the warehouse became the default order.
What teams load into Redshift
Aurora or RDS into Redshift for analytics
The classic AWS pattern, and now the one most likely to need no pipeline at all. Zero-ETL replicates the tables and you model them in Redshift afterwards, as long as every table has a primary key.
SaaS applications into Redshift
Salesforce, HubSpot, Stripe, Shopify and QuickBooks data landed next to product data for revenue reporting. Some of these have a zero-ETL path now, most still need a connector.
Event and log streams
Clickstream, application logs and telemetry delivered continuously through Data Firehose, where buffer settings rather than the tool decide how fresh the data actually is.
On-premises databases into AWS
SQL Server or Oracle estates that are not moving to the cloud yet but whose data has to be reportable alongside everything else. DMS is the usual answer because zero-ETL does not reach outside AWS.
Warehouse to warehouse migration
Moving between Redshift and Snowflake or BigQuery, or running two during a transition. Type mapping and identifier case are where these projects break, not the transfer itself.
Redshift back out to the applications
Once the modeled result exists, someone wants it in the CRM. That is the reverse direction, with its own failure modes around API rate limits and upsert matching.
That last one, pushing modeled results from Redshift back into Salesforce, HubSpot or NetSuite, is a separate purchase with separate failure modes. It is covered on reverse ETL tools.
When another Redshift ETL tool is the right answer
We would rather you buy the correct thing than churn in month three. Five situations where Adapters is not what you want.
Zero-ETL already covers your source
If the data is in Aurora, RDS for MySQL or DynamoDB and the prerequisites hold, AWS will replicate it for you with no pipeline. Paying any vendor, us included, to do the same job is money spent on a solved problem.
You need hundreds of connectors
If the requirement list runs to forty SaaS sources including several obscure ones, buy catalog breadth. Fivetran and Airbyte have spent years on that surface area and we have not.
Everything must stay inside AWS
If security says data never leaves your AWS account, Glue and DMS answer that architecturally. A managed cloud service, ours included, does not.
You need heavy custom transformation
We do field-level mapping and no-code transforms, not distributed Spark jobs with joins, windowing and branching. That is Glue's territory, or dbt if you would rather write SQL.
Your volume genuinely is enormous
Flat pricing is a bet that most teams move a predictable amount of data. If you are loading billions of rows a month, negotiate a volume contract with a metered vendor and you will likely beat our list price. Our advantage is the middle, where a metered bill is unpredictable and a hand-built loader is a permanent staffing cost nobody put on the budget.
Four questions to ask on every Redshift ETL demo
Question 01
Why not zero-ETL for this source?
Ask the vendor directly. A good answer names a real constraint, such as a missing primary key or a source AWS does not cover. A vague answer tells you something too.
Question 02
Does it COPY from S3 or INSERT row by row?
This single design choice decides load performance on a columnar MPP database. Ask how it stages files and how many it writes per run.
Question 03
What types does it choose in Redshift?
Ask to see the CREATE TABLE it generates, including the VARCHAR widths. A column sized too small fails the load, and one sized at the maximum wastes memory on every query.
Question 04
What happens when 40 rows fail?
You want the per-record error log with the source values attached, the retry behavior, and the alert path. Partial failure is the normal case, not the edge case.
The rest of the warehouse shortlist
Redshift is one of three destinations most teams are choosing between. Each page below covers one of them the same way: the native loading paths, the vendors that wrap them, and the limits that decide the architecture.
Questions buyers ask about Redshift ETL tools
- What are Redshift ETL tools?
- Redshift ETL tools are the platforms that move data from your source systems into Amazon Redshift tables and keep them current. Most of them run ELT rather than ETL: they land raw data in Redshift first, then transform it with SQL inside the warehouse, because Redshift compute handles that reshaping better than an external engine does.
- Does AWS have its own ETL tool for Redshift?
- Several. AWS Glue is the serverless ETL service, Database Migration Service handles ongoing database replication, Data Firehose streams events in, and zero-ETL integrations replicate Aurora, RDS, DynamoDB and several SaaS applications into Redshift with no pipeline at all. Most published comparisons of this category predate zero-ETL and are missing the option that is often now correct.
- What is the best ETL tool for Redshift?
- There is no single best one, only a best fit. If the source is Aurora, RDS or DynamoDB, zero-ETL is hard to beat because there is no pipeline to run. Fivetran wins on managed connector breadth, Airbyte on catalog size and self-hosting, Glue when you want Spark inside AWS, and Adapters when you need a handful of dependable syncs on a flat monthly bill.
- What is Redshift zero-ETL?
- Zero-ETL is an AWS feature that replicates tables from a source such as Aurora, RDS, DynamoDB, Salesforce or SAP into Redshift automatically, with no pipeline for you to build or operate. AWS manages the replication. In exchange the destination database is read only, no transformations happen in flight, and every source table must have a primary key.
- What are the limitations of Redshift zero-ETL?
- The main ones: the target must be Redshift Serverless or an RA3 or RG cluster with encryption and case sensitivity enabled, the destination database is read only, source tables must have a primary key, no transformations are applied in flight, and you are capped at 50 integrations per Redshift warehouse. Minimum latency is 15 minutes for DynamoDB and 1 hour for application sources.
- How much does Redshift ETL cost?
- It depends on which half you mean. AWS charges for the Redshift capacity the load consumes, and zero-ETL integrations themselves carry no separate per-integration fee, so you pay for storage and compute. Third-party vendors bill separately, usually by volume: Fivetran meters monthly active rows and Airbyte meters credits. Adapters is flat at $49 to $399 a month.
- How do I load data into Redshift?
- Use COPY from Amazon S3 for anything large, because it loads files in parallel across the cluster slices. Avoid row-by-row INSERT entirely. Redshift automatically splits uncompressed CSV and columnar files of 128 MB or larger, and for formats it cannot split, AWS recommends manually splitting into files of 1 MB to 1 GB after compression, in a multiple of the number of slices.
- Can you do ETL without a tool in Redshift?
- Yes, and for some sources you should. COPY from S3 plus a staging table and a MERGE covers scheduled batch loading with no vendor at all. Zero-ETL covers Aurora, RDS and DynamoDB with no pipeline. You start needing a tool when the source is a SaaS application without a zero-ETL integration, or when you need transformation, retries and alerting.
- Is Redshift ETL or ELT?
- Redshift is the destination, not the process, so it is neither by itself. The pattern nearly every team runs on it is ELT: land raw data with COPY or zero-ETL, then transform it with SQL or dbt inside Redshift. Zero-ETL pushes this further, because it explicitly does not support transformations in flight and expects you to model afterwards.
For the categories around this one, see iPaaS platforms when the job is keeping business applications in agreement rather than filling a warehouse, and ETL software for how our own pipeline works end to end.
Load your sources into Redshift on a flat monthly price
Map the columns once, pick a schedule, and let it run with retries, alerts and per-record logs. From $49 a month, with no row meter and no credits to forecast.
No credit card required.