Stripe and Postgres Dashboard: See Which Users Will Pay, and Who's Slipping Away

A Stripe dashboard stops at what Stripe knows: MRR, new customers, churn. Join it to your app’s Postgres database and it answers what Stripe can’t: which things people do in their first week make them pay, and which paying customers have stopped using the product.

You built the app, so you can query anything. In practice you open Stripe to check MRR, open a SQL client to count signups, and never get round to joining the two. Stripe knows who pays. Your database knows what everyone did. Neither knows the other exists.

This dashboard joins them on the one column most SaaS apps already have, the Stripe customer id on an account, and puts the answers on one page you can read in a minute each morning. We’ll walk through it with Shiplog, a sample changelog tool whose Postgres tables and Stripe account are shaped exactly like the data Infograph syncs. Connect your own and every panel reads your numbers instead.

As likely to pay within 30 days, for signups who installed the widget in week one

7.1x

Source: This dashboard: signups from 30 to 120 days ago

Of MRR from 26 paying accounts that haven't used the app in two weeks or more

$1,337

Source: This dashboard, today

Customers lost to a failed card who were still using the app in their last two weeks

11 of 12

Source: This dashboard, last 90 days

Joining Postgres and Stripe

Two connections, both read-only, and no tracking code to add:

1. PostgreSQL. The tables your app already writes: accounts with their Stripe customer id, and an events or activity table, so signups and usage come straight from the source of truth. How to connect PostgreSQL.

2. Stripe. Customers, subscriptions, invoices and charges, so MRR is worked out from what Stripe actually billed, and every cancellation carries Stripe's own reason, including a card that failed. How to connect Stripe.

3. 

   One Infograph dashboard, each source kept fresh on its own, with nothing exported or copied.

The join is a single column. Here is one Shiplog account across the three tables the dashboard reads:

How to read the Stripe and Postgres dashboard

Start with what moved MRR

The headline is today’s MRR and how far it moved in the period you pick: 7, 30 or 90 days. Beside it, a bridge splits the change into its parts: new customers, upgrades, downgrades, cancellations and failed cards.

A flat month can hide strong sales and heavy churn cancelling each other out, and each needs a different fix. For Shiplog: $19,949 MRR, up $1,577 in 30 days. 51 new customers added $2,139 and upgrades $290, while cancellations took $703, downgrades $100 and one failed card $49.

The six tiles under it compare each figure with the period before. Over 30 days Shiplog looks healthy: new paying customers up 24%, 9.1 customers for every 100 signups, up 13%. Switch to 90 days and it’s less tidy. MRR is up 24%, but conversion has slipped 13% to 7.9 per 100 signups, and MRR lost to churn is up 21% to $2,278. Revenue growth is hiding a leak at both ends, and the panels below show where.

Find the action that makes people pay

This is the panel you can’t get from Stripe or your database alone. It takes everyone who signed up 30 to 120 days ago, so each has had a full month to decide, and asks of each first-week action: how often did the people who did it pay, against the people who didn’t?

For Shiplog the answer is plain. Installing the widget on their own site is the moment that sells: 23.1% of those signups paid within 30 days, against 3.3% of everyone else. Importing subscribers looks like engagement, a third of signups do it, but it barely changes who pays.

It shows which actions go with paying, not that they cause it: people who were going to pay anyway may simply do more. But it tells you which bet to make first. Point half of new signups at the widget in their onboarding, and this panel shows you within a month whether more of them pay. Your own app has a moment like this, and your events table and Stripe can find it.

The funnel beside it shows where people stop on the way. For Shiplog, 82% create a project and 55% publish a post, then the biggest drop comes at the widget: 52% of those who publish never install it. The step that predicts paying is also the one most people skip.

Work the list of quiet customers

A customer rarely cancels out of nowhere. They stop logging in first, sometimes for months, and then a charge reminds them. This list finds them: every paying Stripe customer whose account has had no event in your database for 14 days or more, with the most valuable first.

For Shiplog, 26 accounts worth $1,337 of MRR have gone quiet, and only 3 have already asked to cancel. Fable Apps hasn’t logged a single event in 434 days and still pays $149 a month for the Team plan. Start with the top five: a short, personal email asking what changed.

Rescue the customers who didn’t mean to leave

Stripe records why every subscription ended. Put that beside your usage data and churn splits in two: people who chose to leave, and people whose card failed while they were still using the product.

Over 30 days the bridge shows one failed card costing $49, which looks like nothing. Over 90 days the picture changes. This panel counts every subscription that ended in those 90 days, including ones that started in them, so its totals run higher than the bridge’s. For Shiplog, 12 of the 61 customers lost left because a card failed, and 11 of those 12 were still using the app in their last two weeks. Of the 49 who cancelled, only 7 were. Right now Stripe is retrying five more cards worth $345, and all five accounts used Shiplog this week. Send those five a link to update their card today.

Build it from your Postgres and Stripe

1. Connect your app's database

   Infograph connects from a fixed address, shown in the Postgres guide, so first let it through your firewall or security group, or connect through an SSH server if your database is private. Then create a read-only user, connect, and pick the tables you want: your accounts or users, and your events or activity table. Most Postgres hosts have their own guide.

   • PostgreSQL: how to connect itConnect
   • Supabase: how to connect itConnect
   • Neon: how to connect itConnect

2. Connect Stripe

   Create a restricted key with Read on the resources the Stripe guide lists, and paste it in. A resource left at None still connects, but its table shows an error.

   • Stripe: how to connect itConnect

3. Check you can join the two

   Infograph needs one way to match an account in your database to a customer in Stripe. Most apps store the Stripe customer id on the account or user when they first check out; a column like stripe_customer_id is all it takes. If you don’t keep one, the email on your users table and on Stripe’s customers works too. For the usage panels, any table that records what people do will do, as long as each row has an account id, a timestamp and the kind of event.

4. Prompt your Infograph AI

   Say what you want to know about your product and your revenue, and let Infograph work out the queries. Add whatever matters to how you run your SaaS. Something like this:

   Build me a dashboard I can check every morning for my SaaS, using my app’s Postgres database and Stripe. I want to see where MRR stands and what moved it, which things people do in their first week predict that they’ll pay, which paying customers have stopped using the product, and whose card is failing while they still use it. Match accounts to Stripe customers on the customer id we store, and treat each kind of event in a signup’s first 7 days as a possible reason they paid. Count an account as quiet after 14 days with no events, and judge signups from 30 to 120 days ago on whether they paid within 30 days.

   AddTrialsPlansSignup sourceLists first

   CopyCopiedCopy failedSend to Infograph

Stripe and Postgres dashboard questions