How to build Paddle revenue dashboards in Metabase

Paddle is the merchant of record for your subscriptions, handling billing, payments, and sales tax. Metabase is where you turn that billing activity into shared, trustworthy dashboards. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Paddle into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.

How do you connect Paddle to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Paddle connector. So connecting Paddle to Metabase means one thing: run a small pipeline that copies Paddle data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from Paddle data in Metabase?

• MRR and ARR — recurring revenue now and its monthly movement
• Churn and retention — customer and revenue churn, gross and net retention
• Gross vs. net revenue — what's billed vs. what you keep after tax and fees
• Failed payments and dunning — declines, recovery, and involuntary churn
• LTV and ARPU — value per customer and per account
• Cohort revenue — how each signup cohort retains and grows
• Refunds and adjustments — chargebacks, credits, and their revenue impact

Which Paddle dashboards should you build in Metabase?

How do you build the Paddle → Metabase pipeline?

For dashboards that need history and reliability, land Paddle data in a database first, then connect Metabase to that database.

Connector options

• dlt (free, code) — write a Python pipeline against the Paddle API for full control of streams and schema.
• Paddle API (free, raw) — the source of truth; paginate subscriptions, transactions, and customers and sync on a schedule.
• Paddle webhooks / notifications (first-party) — subscribe to subscription and transaction events and upsert them into your database for a full history.
• Airbyte custom source— no native Paddle source today; build one with the open-source CDK or use webhooks/API instead.

Notes

• Land raw tables first, then build clean models on top.
• Paddle amounts are integer minor units (sometimes strings) — cast and divide by 100 in your model layer.
• As merchant of record, Paddle reports total, tax, and earnings — model gross vs. net so tax isn't counted as revenue.
• MRR is derived: build it from active subscription items and prices.

Can you generate a Paddle dashboard with AI?

Yes — and once Paddle data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp

{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the Paddle Revenue Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Create a polished Metabase dashboard for Paddle revenue analytics using the
available Paddle tables in this database.

Goal: Help founders and finance leaders understand recurring revenue, churn,
retention, failed payments, and net revenue from Paddle data.

First, inspect the schema and identify the available Paddle tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Customers, Subscriptions, Subscription items, Products, Prices,
Transactions, Transaction line items, Adjustments (refunds/credits), and Discounts.

Important:
- Build the dashboard from durable database/warehouse tables.
- Compute MRR from active subscription items, normalizing every price to a monthly
  amount and converting amounts from the smallest currency unit (amounts are stored
  as integer minor units, sometimes as strings).
- Paddle is a merchant of record: separate gross billed amount from net revenue
  after tax and Paddle fees. Do not report tax collected as your revenue.
- Report revenue in a single reporting currency; if multiple currencies exist,
  convert with a documented rate or caveat the mix.
- Separate voluntary churn from involuntary (failed-payment) churn.
- Do not claim Metabase connects natively to Paddle unless that is explicitly
  true in this environment.

Dashboard title: Paddle Revenue Overview

Sections:
1. Executive summary (KPI cards): MRR; ARR; Active subscriptions; Net new MRR this
   month; Gross revenue churn %; Net revenue retention (only if MRR-movement data
   can be derived).
2. MRR movement: New, expansion, contraction, and churned MRR by month.
3. Churn & retention: Customer vs. revenue churn by month; Gross vs. net retention;
   Scheduled cancellations.
4. Failed payments & dunning: Failed transactions and $ at risk; Recovery rate;
   Past-due subscriptions by age.
5. Net revenue & cohorts: Gross vs. net revenue by month; Revenue retention by
   signup-month cohort; Cumulative LTV by cohort; ARPU by product.

Filters: Product, Price, Billing interval, Currency, Country, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_paddle_customers, modeled_paddle_subscriptions, modeled_paddle_transactions,
and modeled_paddle_mrr (a monthly per-subscription MRR model).

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric that
cannot be calculated from the available schema. Reconcile totals against the Paddle
dashboard and payouts. Keep it practical, dense, and executive-readable. Avoid
vanity metrics.

How should you model Paddle data in Metabase?

Core tables

Modeling advice

• Build a modeled_paddle_mrr table: one row per subscription per month with a normalized monthly amount.
• Split gross billed, tax, and net earnings into separate model columns so you never report tax as revenue.
• Normalize prices to a monthly figure and to one reporting currency.
• Read scheduled_change to find subscriptions set to cancel or pause at period end.
• Reconcile net earnings against Paddle payouts.

Which Paddle metrics should you track in Metabase?

What SQL powers Paddle dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect, amounts in minor units). Adjust identifiers to match your warehouse.

WITH monthly AS (
  SELECT
    si.subscription_id,
    SUM(
      CASE p.billing_interval
        WHEN 'year'  THEN p.unit_price_amount / 100.0 / 12.0
        WHEN 'month' THEN p.unit_price_amount / 100.0
        WHEN 'week'  THEN p.unit_price_amount / 100.0 * 52.0 / 12.0
        WHEN 'day'   THEN p.unit_price_amount / 100.0 * 365.0 / 12.0
      END * si.quantity / NULLIF(p.billing_frequency, 0)
    ) AS mrr
  FROM subscription_items si
  JOIN prices p        ON p.id = si.price_id
  JOIN subscriptions s ON s.id = si.subscription_id
  WHERE s.status IN ('active', 'past_due')
  GROUP BY si.subscription_id
)
SELECT ROUND(SUM(mrr), 2) AS mrr_now,
       ROUND(SUM(mrr) * 12, 2) AS arr_now
FROM monthly;

SELECT
  date_trunc('month', t.billed_at)          AS month,
  ROUND(SUM(t.details_totals_total)  / 100.0, 2) AS gross_billed,
  ROUND(SUM(t.details_totals_tax)    / 100.0, 2) AS tax_collected,
  ROUND(SUM(t.details_totals_earnings) / 100.0, 2) AS net_earnings
FROM transactions t
WHERE t.status = 'completed'
  AND t.billed_at >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;

SELECT
  date_trunc('week', t.created_at) AS week,
  COUNT(*)                          AS failed_transactions,
  ROUND(SUM(t.details_totals_total) / 100.0, 2) AS dollars_at_risk
FROM transactions t
WHERE t.status IN ('past_due', 'canceled')
  AND t.created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing Paddle in Metabase?

Related

Related analytics

Related metrics

Related integrations

FAQ