Stripe Data Pipeline's Postgres sync is in public preview, with Neon selectable in the Dashboard

Stripe writes into the same Postgres database as the app, so the app's side of this is a query. Connect an existing Neon project and billing data is "a join away" ^[9]. Neon's examples assume a users table that stores each user's Stripe customer ID, and a feature gate that queries stripe.subscriptions. By Neon's account, when a trial customer is upgraded, the new subscription has already landed in that table ^[10].

Neon's case against the old paths is specific. An API read for one question often takes several calls ^[5]. Neon lists four: fetch the customer, list their subscriptions, look up the price, check the latest invoice ^[14]. A scheduled sync cuts the calls, but the copy is only as current as the last run ^[6]. Webhooks lose an event if the endpoint is down or a handler errors, and an older update processed after a newer one leaves stale state ^[7].

The pipeline's answer to those failures is an audit. Stripe checks the synced data on an ongoing basis, so the app does not reconcile missing or out-of-sync records itself ^[16].

That is a claim about behavior, and the post does not back it with a measurement. It does not include a latency figure for "real-time", a statement on how out-of-order updates are handled, or a price beyond a free start ^[2]. The account is Neon's. Neon is one of the destinations selectable from the Stripe Dashboard, and the post points to Stripe's docs for details ^[12].

Every example in the post is a read: a feature gate, an invoice history, a sales and refund aggregate, a win-back list of customers who canceled and have not resubscribed ^[11]. Reads are what a synced table does well. We'd run the pipeline beside the existing handlers through one billing cycle, diff the two, and delete a handler only after the table has matched it every time.