Stripe to ClickHouse: How to Move Your Data

Moving Stripe into ClickHouse gives you payment data in an engine fast enough to sit behind a live dashboard, at a fraction of the operational overhead of a full warehouse. Stripe knows what was charged, refunded and disputed, and nothing about who used your product or what it cost to serve them.

This guide covers the managed path with Airbyte. Two behaviours shape the build, and both produce rows that arrive more than once: Stripe re-reads recent data on purpose, and ClickHouse collapses duplicates on its own schedule rather than yours.

Stripe to ClickHouse at a glance:

Why move data from Stripe to ClickHouse?

Two situations account for most of these pipelines.

The first is serving revenue figures fast. If you already run ClickHouse behind an internal tool or a customer-facing dashboard, putting payment data next to the event data already there means one engine answering both, in milliseconds, without a warehouse bill attached.

The second is joining. Revenue next to product usage and support load is where the useful answers are, and ClickHouse handles that at a fraction of the operational overhead. If you only need Stripe's standard reports, Stripe already produces them.

What do you need before you start?

Short list, and one item is a decision your finance team should make rather than you:

A restricted Stripe API key and your account identifier. Stripe lets you create keys with read-only access to specific resources, which is exactly what a replication pipeline should have. The Stripe source documentation covers the configuration fields.

A deliberate start date. Data on and after this date is replicated. Finance questions reach further back than product ones, so ask before choosing, and remember a long backfill on a busy account is a substantial first sync.

A lookback window agreed with finance. It defaults to zero, meaning nothing is re-exported after it has been synced. Since payments are adjusted after the fact, zero is rarely the right answer, and the right answer depends on how long your adjustments typically take.

A ClickHouse instance and credentials. With permission to create tables in the target database. The destination writes through the native protocol into typed columns rather than storing everything as JSON in a raw table.

If your ClickHouse instance restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.

How do you build a Stripe to ClickHouse pipeline in Airbyte?

Step 1: Ask how long adjustments take

Ask your finance team how long after a payment things typically still change: refunds issued, disputes raised, adjustments applied. That period is your lookback window, and it is a business fact rather than a technical setting. Getting it from them takes five minutes and getting it wrong produces figures that disagree with Stripe.

Step 2: Configure the Stripe source

Click Sources in the left navigation, then New Source, and select Stripe, following adding a source. Supply the account identifier, the API key, a start date and your lookback window. There is also a data request window controlling the slice size used when asking Stripe for data, which is the setting to reduce if a large backfill struggles.

Step 3: Configure the ClickHouse destination

Click Destinations, then New Destination, and select ClickHouse, following adding a destination. Supply host, port, database and credentials. Deduplication uses the ReplacingMergeTree table engine, and for it to order duplicates correctly your cursor should be a timestamp rather than a string, which on Stripe records it naturally is.

Step 4: Use a deduplicating sync mode

Click Connections, then New connection, select your streams and choose incremental append and deduped as the sync mode. A lookback window deliberately re-reads recent records, so deduplication is what stops that overlap becoming permanent duplicate rows. Daily suits financial data, which settles over days rather than seconds.

Then reconcile a closed month against Stripe's own reporting before anyone builds on it. This is finance data somebody will be held to, and a discrepancy found now is a configuration question while one found later is a credibility problem.

Why do duplicates arrive, and then disappear?

Two separate mechanisms are at work and it is worth keeping them apart, because the fixes differ. On the source side, the lookback window makes Stripe return records you already have, deliberately, so that updated conversion and refund data reaches you.

On the destination side, ReplacingMergeTree collapses duplicate rows during background merges rather than on write. So a query run shortly after a sync can legitimately return rows that the same query returns cleanly an hour later, which is expected behaviour rather than a fault.

Together they mean using a deduplicating sync mode and adding FINAL where exact figures matter. On payment data that is most places, so put revenue totals behind a view that uses FINAL and tell your analysts which tables are safe to query directly. Nobody wants to explain why a dashboard double-counted a month's revenue.

Why does the lookback window not apply to every stream?

Because the connector has two ways of finding changes. Some streams use event-based incremental syncs, discovering what changed from Stripe's own record of events, which catches updates without needing to re-read anything. Others do not, and rely on a cursor instead.

The lookback window applies only to the second group. That is stated plainly in the documentation and is easy to miss, and it means setting the window to seven does not cause a seven day re-read across the board. On the event-based streams it does nothing, because those streams already learn about changes another way.

The practical consequence is diagnostic. If a figure on one stream corrects itself over the following days and the equivalent figure on another does not, that difference is by design rather than a fault. Combined with the merge behaviour above, it means two unrelated reasons a Stripe number in ClickHouse can look wrong, and knowing which you are looking at saves a great deal of time.

Frequently asked questions

Why are there duplicate rows in my tables?

Two reasons, both expected. The lookback window re-reads recent records on purpose, and ReplacingMergeTree only collapses duplicates during background merges. Use a deduplicating sync mode and query with FINAL where figures matter.

What should I set the lookback window to?

However long your payments typically take to settle, including refunds and disputes. It defaults to zero, which re-exports nothing, and that is rarely right for financial data.

Why does the lookback window seem to have no effect on some streams?

It applies only to streams that do not support event-based incremental syncs. Streams that do already discover changes through Stripe's events.

Are deleted records removed from ClickHouse?

No. On the streams that support it, records are marked with a deleted flag when the event occurs upstream. Filter on that flag in your views, or your counts will not match Stripe.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want ClickHouse views using FINAL and filtering deleted records, which is a short piece of SQL and where your revenue definitions belong.

Get your Stripe data into ClickHouse

Agree the lookback window with finance rather than leaving it at zero, use a deduplicating sync mode, put revenue totals behind a view that uses FINAL and filters the deleted flag, and reconcile a closed month before anyone reports on it.

Airbyte's connector catalog includes 600+ pre-built connectors, so payment data can sit beside the product and support sources that explain it. For the same source in a warehouse, see Stripe to BigQuery, and for another financial source landing in ClickHouse, HubSpot to ClickHouse.

Start syncing now →