Tidemill computes MRR, churn, retention, LTV — and ships the SQL behind every number. Self-host alongside Stripe and your accounting platform. Audit any metric down to the row.
A tight surface area, built so every part is legible. The product is the SQL, the schema, and the events — not a black box.
Each metric (MRR, churn, retention, LTV…) lives in a self-contained Python module with its formula, SQL, edge cases, and API in one place. Compiled SQL travels through a typed query algebra — never string concatenation.
# tidemill/metrics/mrr/metric.py @register class MRR(Metric): """Active recurring revenue at time t.""" def query(self, spec) -> Select: ...
Stripe (webhooks → Kafka → PostgreSQL) is the revenue pipeline. QuickBooks Online feeds expense data. Same-database mode supports billing engines that expose a PostgreSQL. Add a new connector in < 200 LOC.
docker compose up.PostgreSQL + Redpanda + FastAPI + a React dashboard, behind Caddy with auto-TLS. Deploys on a single €4/mo Hetzner box, or a k3s HA cluster. Your data stays on your infrastructure.
Six metric families ship today. Each one is a separate module with its own tables, event handlers, and API routes — adding a new metric requires zero changes to existing code.
Σ subscription.mrr_cents WHERE active AT t
churned_mrr / starting_mrr
cohort_mrr(t) / cohort_mrr(start)
ARPU / monthly_churn_rate
converted / started
Σ bill.total_base_cents per period
CAC, warehouse export, and additional connectors are next. Roadmap on GitHub →
A Python class declares the metric. A typed query algebra compiles it to SQL. FastAPI exposes the result. Same chain for every metric — including the ones you write.
@register class MRR(Metric): """Active recurring revenue at t.""" async def query( self, spec: QuerySpec ) -> Select: c = self.cube return spec.fragment( select=[ c.sub.mrr_base_cents .sum().label("mrr"), ], where=[c.sub.is_active_at(spec.at)], )
-- generated, never concatenated SELECT SUM(s.mrr_base_cents) AS mrr FROM subscription s WHERE s.status IN ('active', 'past_due') AND s.started_at <= '2026-04-30' AND (s.ended_at IS NULL OR s.ended_at > '2026-04-30');
$ curl https://tidemill.xyz/api/\ metrics/mrr?at=2026-04-30 // response { "metric": "mrr", "at": "2026-04-30", "value": 13720000, "currency": "USD" }
Webhook-style billing systems get an event pipeline. Database-accessible ones get queried in place. The metric code doesn't care.
Webhooks are translated into typed internal events, fanned through Kafka, and materialized into analytics-owned PostgreSQL by per-metric handlers. Replayable, observable, idempotent.
For billing engines that already own a PostgreSQL, Tidemill connects directly. No Kafka, no ETL, no duplication. The same metric module — with a different cube definition — reads native tables.
MRR, churn, LTV — every closed tool computes them differently, and none show their work. When your numbers don't reconcile with the spreadsheet, you have no recourse. Tidemill ships the SQL.
Hybrid pricing, usage-based, prepaid credits — 85% of vendors will use them by 2026. Generic formulas can't cope. Open code can. Fork a metric, change the SQL, run it.
Run Tidemill on infrastructure you own. Customer revenue data stays inside your network — no third-party SaaS analytics tool sitting between you and your numbers.
The live app at app.tidemill.xyz runs on seeded Stripe data over an 18-month window. Every chart is rendered by the same metrics engine you can clone and run on your own infra in minutes.
make seed