Stripe to Amazon Redshift: How to Move Your Data
Move Stripe into Amazon Redshift with Airbyte. Why the lookback window defaults to zero, the S3 staging requirement, and handling flagged deleted records.
Moving Stripe into Amazon Redshift is how payment data stops being a separate conversation. Stripe knows what was charged, refunded and disputed, and nothing about what those customers cost to acquire, how much support they needed, or whether they used the product they paid for.
Two things shape this build. One source setting defaults to zero and is the usual reason a reconciliation does not balance, and Redshift cannot be loaded without a staging bucket, which adds an AWS prerequisite to a payments pipeline.
Stripe to Amazon Redshift at a glance:
Why move data from Stripe to Amazon Redshift?
Two situations account for most of these pipelines.
The first is revenue analysis your finance team will stand behind. Cohort retention, lifetime value and refund patterns are definitions people argue about, and settling them once in a warehouse beats three teams each computing them from a different Stripe export.
The second is joining payments to the rest of an AWS estate. If your product events, support data and marketing sources already live there, bringing payment records across puts everything in reach of one set of queries.
What do you need before you start?
The lookback decides whether your numbers reconcile, and the bucket is a prerequisite you cannot skip:
A restricted API key with read access. Created in your Stripe dashboard. Use a restricted key rather than a secret key, granting read permissions only on the resources you intend to sync. The Stripe source documentation covers the setup.
A lookback window that is not zero. It defaults to zero, which means cursor-based streams never revisit a period once read. Setting it to a few days costs almost nothing against a deduplicating destination and covers the cases below.
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 start date and Redshift entities. Finance questions reach further back than product ones. On the warehouse side you need a database, a schema and a user able to write data and manage staging operations, and Airbyte writes into two schemas rather than one.
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 Stripe to Amazon Redshift pipeline in Airbyte?
Step 1: Agree what finance needs to reconcile
Ask which Stripe figures somebody will compare your warehouse against, because that tells you which streams matter and how far back to go. Charges, invoices, payouts and balance transactions cover most reconciliation work, and the rest can wait until somebody asks.
Step 2: Configure the Stripe source
Click Sources in the left navigation, then New Source, and select Stripe, following adding a source. Enter the account identifier, your restricted key and a start date, then set the lookback window rather than leaving it at zero.
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: Deduplicate and set your keys
Click Connections, then New connection, select your streams and choose incremental append and deduped as the sync mode. That is what makes a lookback window free. Set sort keys on the transaction date too, since financial reporting is almost always filtered by period.
Then reconcile a closed month against Stripe's own reporting before anyone builds on it, because a discrepancy found now is a configuration question while one found later is a credibility problem.
Why does the lookback window only help some streams?
Because the connector reads your data two different ways. Event-based streams discover changes from Stripe's own event feed, so they learn about an update whenever it happens. Cursor-based streams filter on a timestamp and move forward, which means they can only find what the timestamp exposes.
The lookback window applies to the second group only, and that is the group where a record can change without its cursor advancing. A dispute resolved weeks after the charge, or a backdated adjustment, is exactly the kind of thing a zero lookback never revisits.
So set it to a few days at minimum and longer if your business has slow-settling records. Against a deduplicating destination the cost is a slightly longer sync and nothing else, and the benefit is that finance stops finding gaps you cannot explain.
What happens when something is deleted in Stripe?
It arrives carrying a deletion flag rather than disappearing from your tables. That is the right behaviour for financial data, because a record that vanished without trace would be impossible to audit and awkward to explain to anybody asking what changed.
It does mean your queries have to account for it. A revenue total that does not filter on that flag includes records Stripe no longer considers current, and the difference will not be large enough to look obviously wrong, which is the worst size for an error to be.
Handle it once in a view rather than in every query. On Redshift that view is also where you hide the two-schema arrangement and Airbyte's metadata columns, which gives your reporting a stable interface that survives a connector upgrade.
Frequently asked questions
Why do my Stripe totals not match the dashboard?
Check the lookback window, which defaults to zero, and whether your query filters out deleted records. Those two account for most reconciliation gaps.
Does the lookback window apply to every stream?
No. It applies to cursor-based streams only. Event-based streams learn about changes from Stripe's event feed and do not need it.
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.
Are deleted records removed from my tables?
No. They arrive with a deletion flag, which suits financial auditing. Filter on that flag in a view so every consumer gets the same answer.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. You will want Redshift views filtering deleted records and defining your revenue measures.
Get your Stripe data into Amazon Redshift
Set the lookback window rather than leaving it at zero, use a deduplicating sync mode so that costs nothing, and provision the staging bucket in your cluster's region. Then filter deleted records in a view, sort on the transaction date, and reconcile a closed month before anyone reports on it.
Airbyte's connector catalog includes 700+ pre-built connectors, so payment data can sit beside the product and marketing sources that explain it. For the same source in another warehouse, see Stripe to Snowflake, and for subscription billing alongside it, Chargebee 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.