Stripe Data Pipeline Doesn't Sync to PostgreSQL: What to Use Instead

You went looking for the official answer. Stripe sells a product called Data Pipeline whose entire job is getting your Stripe data out of Stripe and into somewhere you can query it, which sounds exactly like what you need. Then you open the destination list.

Snowflake. Amazon Redshift. Databricks. BigQuery. Google Cloud Storage, Azure Blob Storage, Amazon S3.

No PostgreSQL. No Supabase, no Neon, no RDS. If your stack is a Postgres database, the Data Pipeline you can actually buy today does not meet you there. The two Stripe products that will are both locked behind a preview.

This post covers what Data Pipeline actually is, what Stripe is quietly building for Postgres users and why you probably cannot have it yet, what the cloud storage route really costs if you decide to bridge the gap yourself, and the options that exist today.

What Stripe Data Pipeline Actually Is

Data Pipeline is a paid Stripe product that pushes a copy of your Stripe data to a destination you own, with no code on your side. Per Stripe's documentation, it supports two shapes of destination:

Data warehouses (Snowflake, Amazon Redshift, Databricks, BigQuery). Stripe sends a data share to your warehouse, with one instructive exception covered in the next section. Either way, your core Stripe data is available within 12 hours of setup.

Cloud storage (Google Cloud Storage, Azure Blob Storage, Amazon S3). Stripe drops Parquet files into a bucket you own.

After the initial load, both routes refresh on the same cadence: a new full load of your data every 3 hours, with Stripe noting that some tables update on their own schedules as new data becomes available. Your data is split into a STRIPE schema for live mode and a STRIPE_TESTMODE schema for sandboxes, every table carries a merchant_id column so multiple Stripe accounts can share one destination, and a data_load_times table tells you when each table was last refreshed.

Two things worth knowing that rarely make it into comparison posts. A Data Pipeline subscription includes Stripe Sigma, so you are buying the in-dashboard SQL tool along with the export. And Stripe does not offer Data Pipeline to customers in India, because of data localization requirements.

Why PostgreSQL Is Not on the List

It is tempting to read the destination list as an oversight. The setup mechanics are more interesting than that, and they explain the shape of what Stripe is building next.

Three of the four warehouse destinations arrive as a native data share, a feature of the warehouse rather than anything Stripe operates. In Snowflake you accept a share from a Stripe account and mount it as a database. In Redshift you associate an incoming datashare, which only works on an RA3 cluster with encryption enabled. In Databricks it comes through Delta Sharing and you mount the Stripe share to a catalog. No bytes move through infrastructure Stripe runs. It publishes, you accept, and your warehouse does the rest.

BigQuery is the exception. There is no share: you create a service account, grant it BigQuery Job User and BigQuery Data Editor, stand up an intermediate Cloud Storage bucket for Stripe to write to, and Stripe runs load jobs into your datasets, deleting the intermediate files afterwards.

That exception is the tell. Stripe will operate a real write pipeline into a destination you own when it decides the destination is worth the engineering. Postgres was not on the list because it is the harder version of that problem: not one managed vendor with one stable way in, but millions of instances across every host and self-run box on the internet, each with its own version, extensions, connection limits, pooler, IP allow-list and maintenance window, and no share mechanism to fall back on.

Hard is not the same as never, though, which brings us to the part most comparison posts have not caught up with.

Stripe Is Building Postgres Support, in Two Places

Neither is generally available. Neither is something you can go and buy this afternoon. Both are documented, and both are aimed squarely at the reader of this post.

Real-time sync to Postgres. Stripe's documentation for it is unambiguous: it continuously streams "your Stripe data to a Postgres database", in real time rather than in a 3-hour batch, with a schema that is "a direct mapping to the public Stripe API". Coverage is everything in the public API that has a list endpoint, so charges, customers, subscriptions, payment intents and invoices are in, while single-object resources like Balance are not, and you choose which tables to sync from the Dashboard. The setup guide is public and specific: PostgreSQL 13 or later from any provider, with Stripe naming Amazon RDS and Aurora, Supabase, Neon and self-hosted deployments; a stripe schema reserved for the pipeline; a dedicated database user that owns that schema and holds SELECT, INSERT, UPDATE and DELETE on it; an SSL connection; and sixteen Stripe IP addresses added to your firewall allowlist. Stripe then backfills the tables you picked and keeps them current. The catch is the status: it is still a preview you request access to by email, with no published general availability date, and the commitment is to "a near-real-time basis" with no end-to-end latency SLA.

Stripe Database. Announced at Sessions 2026 as a managed, hosted, read-only Postgres database holding your Stripe data, created in one click from the Dashboard or a single CLI command. Its documentation page returns a 404 unless your account is enrolled in the early access programme, so the substantive public document is the preview terms, which are worth reading before you build anything on it. It is a Preview Service "not subject to Stripe's standard compliance certifications, access controls requirements, or related auditing commitments". Stripe "may, at its discretion, temporarily throttle, rate-limit, or suspend" your access based on query volume. It "reserves the right to apply or change Fees". And on termination, "Stripe will delete all associated data".

So the honest status is that Stripe will probably solve part of this, on its own timeline. Two things stay true when it lands.

It is Stripe only. The real-time Postgres sync syncs Stripe data and Stripe Database holds Stripe data. If your reporting also needs QuickBooks, Xero or Paddle in the same database, that is a second tool or a warehouse regardless.

With Stripe Database, the data lives in Stripe's infrastructure, not yours. That is genuinely convenient, and it is also the opposite of why most people want the copy in Postgres in the first place: to join billing data against their own application tables, own the schema, and keep it somewhere they control.

Until either ships, the practical answer is unchanged. If you want Stripe data in your Postgres today, something other than Data Pipeline has to put it there.

What Data Pipeline Costs, and What the Meter Is

The pricing matters here because it shapes the decision even for people who could adopt a warehouse.

Data Pipeline is priced in tiers based on your monthly charge count, with a per-charge rate on anything above your tier. Read off Stripe's pricing page in September 2026, the entry tier covers up to 1,000 charges a month at $65 a month, or $50 a month on an annual plan, with 7 cents and 6 cents respectively per additional charge. Above that it is annual only: $75 a month up to 2,500 charges, $280 up to 10,000, $550 up to 25,000, and custom pricing beyond. The UK page shows the same ladder at £48 or £37, then £56, £209 and £410. New accounts get a 30-day free trial.

Two things sit in the small print. Monthly billing exists only on the entry tier, so passing 1,000 charges a month means taking on an annual commitment. And the meter counts "successful charges both on Stripe and through third-party payments processors in connection with any Stripe service", so payments you did not run through Stripe at all can still push you up a tier.

Note what the meter is. You are not billed for tables, rows, syncs or queries. You are billed for payment volume, which is to say your business getting busier, for a job whose difficulty does not change when it does. That is the same structural complaint as usage-priced ETL, arrived at from a different direction: Fivetran's monthly active rows model meters row churn instead, with the same result that the bill moves for reasons unrelated to what you asked for.

And this is before the destination. Snowflake, Redshift, Databricks and BigQuery all bill you separately for storage and compute. Adopting a warehouse to receive this data is not a one-line decision.

The Cloud Storage Escape Hatch, and What It Really Costs

Here is the part that a flat "Data Pipeline can't do Postgres" leaves out, and it is the honest centre of this post.

There is a technical path. Point Data Pipeline at S3, GCS or Azure Blob, and Stripe delivers Parquet files into a bucket you control. Nothing stops you writing a job that reads those files and loads them into Postgres. Stripe even helps a little: it writes a SUCCESS file per run date and mode once all files for a set of tables are transferred and validated, and it updates a /data_load_times.json file with the time and location of the most recent successful load for each table.

Now count what you own the moment you take that path.

A loader that reads Parquet. Postgres does not ingest Parquet natively. You are writing a job, in a language of your choice, on a runtime you have to host, or standing up something like DuckDB or a Spark step in between.
Type mapping. Parquet's types are not Postgres types. Timestamps, nested structures, numeric precision and the JSON-shaped fields in Stripe's schema each need a decision, and the wrong one is usually discovered months later inside a report. Our post on designing a Postgres schema for Stripe data covers the choices that bite.
Deduplication, every three hours, forever. This is the big one. Each run is a full load, not a changelog. You are handed the whole dataset again eight times a day, and it is entirely on you to turn that into idempotent upserts against your existing rows rather than duplicates. Get the conflict target wrong once and you are cleaning up a table by hand.
Orchestration and failure handling. Polling for the SUCCESS file, not starting on a half-written batch, retrying, and alerting when a load silently stops.
Schema drift. Stripe adds fields. Your loader has to notice, and your table has to change.
Two bills. You are paying Stripe for Data Pipeline, and paying for the bucket, the egress and whatever compute runs the loader.

None of this is hard in the sense of being intellectually difficult. It is hard in the sense of never being finished. You wanted Stripe data in a table; you have acquired a data pipeline, and pipelines are things people end up on call for. If the appeal of Data Pipeline was "without writing code", the cloud storage route quietly hands the code back.

Today's Version Is Not Real Time

One more expectation worth resetting before you build anything around this.

A 3-hour cadence is not a 3-hour freshness guarantee. Stripe's data freshness documentation works the example: with a 3-hour cadence, a record created at 00:01 UTC is picked up in the 03:00 UTC batch, and with a typical delivery time of about three hours after the batch closes, it lands by 06:00 UTC. That is a P50 freshness of six hours from event creation. Half the time it is slower than that, delivery varies with your data volume, and derived datasets run on their own schedules.

That is completely fine for finance, reporting and analytics, which is what the product is for. It is not fine if you were planning to drive product behaviour off the copy. Real-time streaming is exactly what the Postgres sync in preview promises, which is Stripe's own way of conceding that the shipping product does not do it. Until that is generally available, if you need a customer's subscription state correct within seconds, that is a webhook job rather than a sync job. We covered where the line sits in how often you should sync billing data to Postgres.

Your Real Options for Getting Stripe Data into Postgres Today

Assuming Postgres is not negotiable, these are the paths, with the trade-off named honestly.

Option	What it costs you	Best when
Wait for Stripe's real-time Postgres sync	No money, but no date either, and access is Stripe's decision	Stripe is your only source and the timing genuinely does not matter
Adopt a warehouse	Warehouse bill plus a Data Pipeline tier, and a second system to run	You already run Snowflake, BigQuery, Redshift or Databricks
Cloud storage plus your own loader	Data Pipeline tier, storage, compute, and permanent ownership of the job	You have a data engineer and Parquet is already in your stack
Stripe API plus your own script	Build time, pagination, rate limits, retries, schema upkeep	Your needs are narrow enough that nothing off the shelf fits
Managed sync straight into Postgres	A flat subscription, and a narrower feature set than a warehouse platform	Postgres is the destination and you want the job to be finished

If you want the full field rather than these four, 5 ways to get Stripe data into PostgreSQL walks the methods, and the best tools to sync Stripe data to a database reviews seven products with their weak points included.

When Data Pipeline Is Still the Right Call

It would be a bad post that only argued one way, so here is the case for buying it.

If a warehouse is already in your stack, Data Pipeline is close to unbeatable for Stripe specifically. It is first-party, and Stripe's pitch is that you get "structured and ready-to-use datasets not available through third-party APIs or ETLs", which nothing built on the public API can match. On the three share-based destinations there is no pipeline to run at all. Multi-account businesses can fold every Stripe account into one destination and filter on merchant_id, and Organizations gives administrators a single view of every pipeline. Sigma is bundled rather than sold separately, so the reporting layer arrives with it, which we compared in the best Stripe Sigma alternative for Postgres users.

Two limits to know before committing: you can connect only one warehouse account to a Stripe account at a time, and the pre-built financial report templates are Snowflake only, not available on Redshift, Databricks or BigQuery.

The question is not whether it is a good product. It is whether you are willing to run a warehouse in order to use it.

The Postgres-Native Version

If your destination is Postgres and you want the job to stay finished, that is the narrow problem Codeless Sync exists for.

You connect Stripe with a restricted, read-only API key, choose a data type, and the destination table is created for you in your own database. It works with Supabase, Neon, AWS RDS, Railway, DigitalOcean and any other Postgres you can reach, and the same setup covers QuickBooks, Xero and Paddle if your billing data is not all in one place. The first sync takes about five minutes.

The difference from the cloud storage route is not the setup, it is the ownership. There is no Parquet reader, no type mapping, no dedupe logic, no SUCCESS file to poll, no schema drift to chase. Syncs upsert on the record's Stripe ID, so a re-run corrects rather than duplicates, and rate limits, retries and pagination are ours to worry about.

The pricing is a flat monthly fee rather than a meter on your payment volume. Free is $0 for 2 manual syncs a day, 2 configurations and one database project. Starter is $19 a month, Pro is $29 and Business is $99, each adding configurations and a larger monthly row allowance, with more database projects from Pro upwards. Scheduled syncs are the paid feature: Starter and Pro run daily, weekly or monthly, and Business adds a 12-hourly option.

Put the two next to each other on the axes that actually differ:

	Stripe Data Pipeline	Codeless Sync
PostgreSQL	Not a destination	The only destination
Priced on	Your monthly charge count	Flat monthly fee
Second system needed	A warehouse, or a bucket plus a loader you build	No
Cadence	Full load every 3 hours, P50 about 6 hours old	Manual, or scheduled daily to monthly, 12-hourly on Business
Sources	Stripe	Stripe, QuickBooks, Xero, Paddle
Dataset coverage	First-party, includes data the API does not expose	Common billing tables
Bundled reporting	Includes Sigma	No, you query your own Postgres

Data Pipeline wins coverage and completeness. It cannot win a single row of that table that involves the word Postgres, and that is the row you came here for.

Frequently Asked Questions

Does Stripe Data Pipeline support PostgreSQL?

No. Data Pipeline delivers to Snowflake, Amazon Redshift, Databricks and BigQuery, or to Google Cloud Storage, Azure Blob Storage and Amazon S3. PostgreSQL, including Supabase, Neon and AWS RDS, is not a supported destination.

Is Stripe adding PostgreSQL support to Data Pipeline?

Yes, through a real-time sync to Postgres that is still in preview. Stripe's documentation describes it as continuously streaming Stripe data to a Postgres database, with a schema mapped directly to the public API, and the setup guide is already public: PostgreSQL 13 or later from any provider including RDS, Supabase and Neon, a reserved stripe schema, a dedicated database user, SSL, and sixteen Stripe IP addresses allowlisted on your firewall. You request access by email, and there is no published general availability date.

What is Stripe Database?

A managed, hosted, read-only Postgres database of your Stripe data, announced at Sessions 2026 and still in preview, with documentation gated behind early access enrolment. Note that the data sits in Stripe's infrastructure rather than your own, so you cannot join it against your application tables, and the public preview terms let Stripe throttle access, change fees, and delete all associated data on termination.

Can I get Stripe Data Pipeline into Supabase or Neon?

Not directly. The nearest path is exporting Parquet files to cloud storage and writing your own job to load them into your database, which means owning a loader, type mapping, three-hourly deduplication and schema drift. A managed Stripe to Postgres sync does the same job without the pipeline.

How much does Stripe Data Pipeline cost?

It is tiered on your monthly charge count, with a per-charge rate above each tier. Checked in September 2026, the entry tier covers up to 1,000 charges a month at $65 a month, or $50 a month on an annual plan, and the tiers above it are annual only at $75, $280 and $550 a month for 2,500, 10,000 and 25,000 charges. Warehouse storage and compute are billed separately by your warehouse provider.

How fresh is Stripe Data Pipeline data?

Stripe delivers a full load every 3 hours. Because a record waits for the next batch and then for delivery, Stripe's own worked example comes to a P50 freshness of about six hours from event creation, with delivery time varying by data volume.

Is Stripe Data Pipeline the same as Stripe Sigma?

No, though a Data Pipeline subscription includes Sigma. Sigma runs SQL inside the Stripe Dashboard and returns results there. Data Pipeline copies your data to an external destination you own.

What is the fastest way to get Stripe data into a Postgres database?

A managed sync. Connecting a read-only Stripe key and letting the tool create the destination table takes about five minutes, against the days it takes to build a Parquet loader or a paginated API script, and it keeps working afterwards.

Wrapping Up

Stripe Data Pipeline is a good product aimed at a reader who is not you. It assumes a warehouse, it prices on payment volume, and its Postgres story today is a bucket of Parquet files plus a job you write yourself. The version with a real Postgres destination exists, and it is in preview with no date, which is not something you can plan a quarter around.

If Postgres is where your data lives, skip the detour. Either adopt a warehouse deliberately, for reasons that go beyond this one export, or use something built to land Stripe data in Postgres and be done with it.

Start a free sync and see your Stripe tables in your own database in about five minutes.