How to Forecast Revenue Directly From Your Database

Most companies forecast revenue in a spreadsheet. The problem is that spreadsheets are filled with numbers someone manually copied from somewhere else usually a CRM, a billing tool, or an export someone ran last Tuesday. By the time the forecast is built, the data is already stale.

Your database doesn't have that problem. Every transaction, subscription event, churn, and upgrade is already there, recorded in real time. The question isn't whether your database can support revenue forecasting it's whether you know how to get that data out without a week of engineering effort.

This guide walks through how to do revenue forecasting directly from your database: the SQL patterns that matter, the metrics to track, and how to automate the whole thing so your forecast updates itself.

Why Your Database Already Has Everything You Need

Revenue forecasting requires a surprisingly small number of data points:

All of this data lives in your database. In a typical SaaS or e-commerce setup, you'll have tables like orders, subscriptions, users, payments, and events. The raw material for a revenue forecast is already there it just needs the right queries to surface it.

The bottleneck has never been the data. It's been access. Non-technical team members who own revenue forecasting can't write SQL, and engineers are rarely available to run ad hoc queries on demand.

Key Revenue Metrics to Calculate From Raw Data

Before building a forecast, you need a solid baseline of current metrics. Here are the most important ones and how to calculate them from your database.

Monthly Recurring Revenue (MRR)

SELECT
  DATE_TRUNC('month', created_at) AS month,
  SUM(monthly_amount) AS mrr
FROM subscriptions
WHERE status = 'active'
GROUP BY 1
ORDER BY 1;

Net Revenue Retention (NRR)

NRR measures whether existing customers are spending more or less over time. A number above 100% means expansion revenue is offsetting churn.

SELECT
  cohort_month,
  SUM(CASE WHEN month_number = 0 THEN revenue ELSE 0 END) AS initial_revenue,
  SUM(CASE WHEN month_number = 12 THEN revenue ELSE 0 END) AS revenue_12m_later,
  ROUND(
    100.0 * SUM(CASE WHEN month_number = 12 THEN revenue ELSE 0 END) /
    NULLIF(SUM(CASE WHEN month_number = 0 THEN revenue ELSE 0 END), 0),
    1
  ) AS nrr_12m
FROM customer_revenue_cohorts
GROUP BY cohort_month;

Churn Rate

SELECT
  DATE_TRUNC('month', cancelled_at) AS month,
  COUNT(*) AS churned,
  ROUND(
    100.0 * COUNT(*) /
    LAG(COUNT(*)) OVER (ORDER BY DATE_TRUNC('month', cancelled_at)),
    2
  ) AS churn_rate_pct
FROM subscriptions
WHERE status = 'cancelled'
GROUP BY 1
ORDER BY 1;

Trial-to-Paid Conversion Rate

SELECT
  DATE_TRUNC('month', trial_start) AS month,
  COUNT(*) AS trials_started,
  COUNT(CASE WHEN converted_at IS NOT NULL THEN 1 END) AS converted,
  ROUND(
    100.0 * COUNT(CASE WHEN converted_at IS NOT NULL THEN 1 END) / COUNT(*),
    1
  ) AS conversion_rate
FROM trials
GROUP BY 1
ORDER BY 1;

Building a Rolling Revenue Forecast From Trends

Once you have a clean history of MRR and churn, you can project forward using a simple trend model. The most practical approach is a rolling 3-month average growth rate applied to the current MRR base.

WITH monthly_mrr AS (
  SELECT
    DATE_TRUNC('month', created_at) AS month,
    SUM(monthly_amount) AS mrr
  FROM subscriptions
  WHERE status = 'active'
  GROUP BY 1
),
growth_rates AS (
  SELECT
    month,
    mrr,
    LAG(mrr) OVER (ORDER BY month) AS prev_mrr,
    (mrr - LAG(mrr) OVER (ORDER BY month)) /
      NULLIF(LAG(mrr) OVER (ORDER BY month), 0) AS growth_rate
  FROM monthly_mrr
)
SELECT
  month,
  mrr,
  AVG(growth_rate) OVER (
    ORDER BY month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
  ) AS rolling_3m_growth
FROM growth_rates
ORDER BY month;

This gives you a 3-month rolling growth rate. Apply that rate to your current MRR and you have a reasonable forward projection nothing fancy, but grounded in actual behavior.

Setting Up an Automated Revenue Dashboard That Refreshes Itself

The problem with running these queries manually is that they go stale immediately. A revenue forecast that nobody checks because it requires a developer to refresh is no forecast at all.

The better approach is to build a dashboard that queries your database on a schedule and always shows current numbers.

With AI for Database, you can do this without writing any SQL yourself. Connect your database, then ask plain-English questions like:

The tool translates these to SQL, runs them against your live database, and displays the results as charts or tables. Set a refresh interval and the dashboard updates automatically daily, hourly, or whatever cadence matches your business.

For SaaS teams, a revenue dashboard with five to six metrics (MRR, churn, NRR, new MRR, expansion MRR) gives the full picture without any BI tool setup or manual data exports.

Using Database Alerts to Catch Revenue Problems Early

Forecasting tells you where revenue is going. Alerts tell you when something unexpected happens that will break the forecast.

The most useful database-driven revenue alerts are:

These conditions are straightforward to detect with SQL against your database. The challenge is running those checks continuously and getting notified when something crosses a threshold.

AI for Database's action workflows let you define these conditions in plain English ("send me a Slack message if daily new subscriptions fall below 20") and the system watches your database automatically. No stored procedures, no database triggers, no infrastructure work.

From Spreadsheet Forecasts to Live Database-Driven Models

The shift from spreadsheet-based to database-driven forecasting isn't just about accuracy it changes how the whole team interacts with revenue data.

When the forecast lives in a spreadsheet, it belongs to whoever built it. When it's driven directly from the database, anyone can ask questions and get answers based on the same real-time numbers.

A RevOps manager can ask "what's our expected MRR next quarter if churn stays flat?" and get an answer based on actual subscriber data, not last week's export. A founder can check conversion rates at 9pm without filing a request. A board presentation can reference numbers pulled minutes before the meeting.

The technical barrier to doing this has dropped significantly. You don't need a data warehouse, a BI tool, or a data engineer. You need a direct connection to your database and something that can translate business questions into SQL.