Stripe Sigma explained: what it does, what MRR costs in SQL, and when you need it

Stripe Sigma is an interactive SQL environment inside the Stripe Dashboard: your payments, subscriptions, customers and payouts as queryable tables, read only, no warehouse to stand up. For a finance team doing reconciliation, it is genuinely one of the best things Stripe ships. For a founder who opened it wanting their MRR, it is a fork in the road worth understanding before you commit a weekend to it.

This post is both halves: what Sigma is and does well, and then, in its own words, what computing subscription metrics in it actually involves.

What Sigma is

• SQL over your Stripe account, in the dashboard. Tables for charges, subscriptions, invoices, line items, coupons, disputes, payouts and the rest, joined however you like, in the Trino (Presto) dialect.
• Read only by construction. Queries cannot modify data or create transactions, so there is nothing an analyst can break.
• Free to try in sandboxes. Unlimited queries against test data cost nothing; live-mode Sigma is a paid subscription you can cancel from its settings page.
• Built for reports. Pre-built templates (balance changes, payout reconciliation), scheduled runs, and metric groups that pin up to 20 reports to the dashboard.

The audience Stripe built it for is visible in that list: accounting and reconciliation workflows, where the questions are about money movement and the answers must tie to payouts cent by cent. If that is your job, stop reading and go use it; it is good.

Querying your subscriptions

The billing tables are pleasant to work with. Current subscribers, joined to contact info, is four lines:

select subscriptions.id, subscriptions.customer_id, customers.email
from subscriptions
inner join customers on customers.id = subscriptions.customer_id
where subscriptions.status = 'unpaid'

Products, prices, coupons, trials, meters for usage-based billing: all one or two joins away. For operational lists ("everyone still trialing", "unpaid subscriptions with emails"), Sigma is quick and exact.

Then you try to compute MRR

Stripe provides a table for exactly this: subscription_item_change_events, where every change to a subscription item lands as an event with an mrr_change amount and a type (ACTIVE_START, ACTIVE_END, ACTIVE_UPGRADE, ACTIVE_DOWNGRADE). It is the right raw material, and Stripe's query template library includes a worked example that turns it into monthly MRR with movements.

That template is around two hundred lines of SQL. Not because Stripe over-engineered it, but because the problem genuinely contains all of this:

• Window functions per customer to reconstruct running MRR, because telling a new customer from a reactivated one requires knowing whether their MRR was ever nonzero before.
• A currency conversion layer: a cross join of every active currency against a daily exchange-rate table, using the previous day's closing rates.
• An FX adjustment bucket, derived as the residual after the five movements, so currency drift does not masquerade as expansion.
• Care around same-second events, since one user action can emit an ACTIVE_END on one item and an ACTIVE_START on another in the same subscription.

A taste of the middle of it:

sum(mrr_change) over (
  partition by customer_id
  order by local_event_timestamp asc
) as mrr,
count(nullif(mrr_change, 0)) over (
  partition by customer_id
  order by local_event_timestamp asc
) as mrr_change_count
-- ...later: mrr > 0 and previous_mrr = 0 and mrr_change_count > 1 => 'REACTIVATE'

And two caveats from the docs that matter if you build on it: the fresher subscription_item_change_events_v2_beta table holds a three-hour freshness in Sigma, and Stripe advises letting data settle for up to 48 hours before consuming it incrementally, because recent days can be restated. Your MRR for yesterday is allowed to change today.

None of this is a criticism of Sigma. It is evidence for a claim we make often: MRR is not a query, it is a ledger with policy decisions inside it, and Stripe's own template is what those decisions look like written out in SQL.

The fork in the road

So the decision is really about who you are:

The third and fourth rows are where Kometrics sits: it is, in effect, that two-hundred-line query productized. The same event classification (new, expansion, contraction, churn, reactivation, with FX in its own bucket) runs as a maintained ledger over your billing history, every metric derives from it, and each number opens down to the invoices behind it:

The part Sigma structurally cannot offer is the last row: the ledger is exposed over MCP, so the same figures answer inside Claude, ChatGPT, Claude Code and Codex, read only, with a link back to the report. If your revenue questions get asked in a chat window rather than a SQL editor, that is the difference that matters day to day. It is free under $1,000 MRR, and it reads Paddle, Creem and Asaas alongside Stripe, which no amount of Sigma SQL can.

FAQ

Is Stripe Sigma free?

In sandboxes, yes, with no usage limits. Against live data it is a paid subscription, cancellable from the Sigma settings page in the dashboard.

What SQL dialect does Sigma use?

Trino (the engine formerly known as Presto). Standard joins and window functions work, plus Stripe helpers like stringify_amount.

Can Sigma calculate MRR?

Yes, from the subscription_item_change_events table, and Stripe's template library shows how. Budget for real SQL (window functions, currency handling) and for the freshness caveats: recent days settle for up to 48 hours.

Sigma or Data Pipeline?

Sigma queries your data inside Stripe's dashboard; Data Pipeline ships the same tables to your own warehouse (Snowflake, Redshift) to join with non-Stripe data. Same schema knowledge transfers between them.

Does the Stripe MCP server replace Sigma?

They overlap increasingly: the MCP server's analytics tools (private preview) can run Sigma-backed queries from an AI client. The write-up on where that stands is in the Stripe MCP server, explained.