Database Analytics for Multi-Tenant SaaS: Tracking Metrics Per Customer

If you run a multi-tenant SaaS product, your database is where the real story lives. You can see which customers are active, which ones are fading, who's hitting usage limits, and which accounts show signs of expansion all from raw database data. The problem is that most analytics tools are designed for aggregate metrics. Getting per-customer breakdowns requires SQL that most teams don't have on demand.

This guide covers the key per-customer metrics worth tracking, the SQL patterns to extract them, and how to make this analysis accessible to non-technical teammates without turning it into a permanent engineering burden.

Why Per-Customer Analytics Matter More Than Aggregate Metrics

Aggregate metrics total DAUs, total revenue, overall churn rate tell you how the business is trending. But they don't tell you which accounts are at risk, which segments are most active, or which customers are ready to expand.

Per-customer analytics answer questions like:

These questions directly drive retention, upsell, and customer success actions. They're not hard to answer the data exists in your database but they require flexible, per-tenant queries rather than dashboards that only show totals.

The Multi-Tenant Data Model

Multi-tenant SaaS databases typically follow one of three patterns:

Shared schema, tenant ID column All customers share the same tables, with a tenant_id or account_id column on every row. This is the most common pattern.

-- Example: events table with tenant_id
CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  tenant_id UUID NOT NULL REFERENCES accounts(id),
  user_id UUID,
  event_type VARCHAR(100),
  created_at TIMESTAMPTZ DEFAULT NOW()
);

Separate schema per tenant Each customer gets their own PostgreSQL schema (tenant_abc.events, tenant_xyz.events). Less common but sometimes used for compliance reasons.

Separate database per tenant Each customer has their own database instance. Rare for new products, more common in enterprise deployments with strict data isolation requirements.

The analytics patterns below assume the shared-schema model since it's most common. The concepts translate to the other patterns with minor adjustments.

Core Per-Customer Metrics to Track

1. Activity and Engagement

The most useful signal for churn prediction is usage trend. A customer whose activity is declining week-over-week is worth a proactive outreach, even if they haven't said anything.

-- Weekly active users per account, last 4 weeks
SELECT
  a.name AS account_name,
  DATE_TRUNC('week', e.created_at) AS week,
  COUNT(DISTINCT e.user_id) AS weekly_active_users
FROM events e
JOIN accounts a ON a.id = e.tenant_id
WHERE e.created_at >= NOW() - INTERVAL '4 weeks'
GROUP BY a.name, DATE_TRUNC('week', e.created_at)
ORDER BY a.name, week;

2. Feature Adoption

Knowing which features each customer uses tells you a lot about their depth of engagement and their expansion potential.

-- Feature usage by account in the last 30 days
SELECT
  a.name AS account_name,
  e.event_type AS feature,
  COUNT(*) AS usage_count
FROM events e
JOIN accounts a ON a.id = e.tenant_id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
  AND e.event_type IN ('report_generated', 'dashboard_viewed', 'export_downloaded', 'api_called')
GROUP BY a.name, e.event_type
ORDER BY a.name, usage_count DESC;

3. Plan Limit Proximity

Customers approaching their plan limits are either ready to upgrade or at risk of hitting a wall and churning. Knowing who they are before they hit the limit is the whole game.

-- Accounts using more than 80% of their seat limit
SELECT
  a.name AS account_name,
  a.plan_tier,
  a.seat_limit,
  COUNT(DISTINCT u.id) AS active_seats,
  ROUND(COUNT(DISTINCT u.id)::numeric / a.seat_limit * 100, 1) AS pct_used
FROM accounts a
JOIN users u ON u.account_id = a.id
WHERE u.status = 'active'
GROUP BY a.name, a.plan_tier, a.seat_limit
HAVING COUNT(DISTINCT u.id)::numeric / a.seat_limit >= 0.8
ORDER BY pct_used DESC;

4. Days Since Last Activity

The simplest leading indicator of churn is silence.

-- Accounts with no activity in the last 14 days
SELECT
  a.name AS account_name,
  a.plan_tier,
  MAX(e.created_at) AS last_activity,
  EXTRACT(DAY FROM NOW() - MAX(e.created_at)) AS days_since_active
FROM accounts a
LEFT JOIN events e ON e.tenant_id = a.id
WHERE a.status = 'active'
GROUP BY a.name, a.plan_tier
HAVING MAX(e.created_at) < NOW() - INTERVAL '14 days'
   OR MAX(e.created_at) IS NULL
ORDER BY days_since_active DESC NULLS FIRST;

5. Revenue Concentration Risk

If 3 accounts make up 60% of your MRR, that's a risk worth knowing about explicitly.

-- MRR by account, with percentage of total
SELECT
  a.name AS account_name,
  a.plan_tier,
  a.mrr,
  ROUND(a.mrr / SUM(a.mrr) OVER () * 100, 1) AS pct_of_total_mrr
FROM accounts a
WHERE a.status = 'active'
ORDER BY a.mrr DESC;

Making This Analysis Accessible Without Constant SQL Work

The challenge isn't writing these queries once it's making the answers available to customer success, sales, and leadership teams who don't speak SQL and shouldn't have to.

Two approaches work well:

Approach 1: Saved dashboard panels Build a customer health dashboard with these metrics pre-configured. Non-technical teammates can filter by account name or plan tier without touching SQL. Tools like AI for Database let you build these panels from plain-English questions and set them to auto-refresh, so the data is always current.

Approach 2: Natural language on demand Instead of pre-building every possible view, let teammates ask their own questions. "Which accounts on the Growth plan haven't used the API in 30 days?" is a question a CS manager should be able to answer themselves, without opening a ticket. AI for Database translates questions like that directly into SQL, runs it against your connected database, and shows results.

The difference between the two is mostly about frequency. For metrics you check every morning, build a dashboard panel. For ad hoc investigation ("why did account X churn?"), natural language queries are faster.

Setting Up Automated Alerts for Customer Health Signals

Dashboards require you to remember to look at them. Alerts fire when something happens.

Useful customer health alerts for multi-tenant SaaS:

With AI for Database's action workflows, you define the condition in plain English ("when any account has zero events in the last 10 days") and specify the action (send a Slack message, trigger a webhook, send an email). The system checks your database on a schedule and fires the action when the condition is met no stored procedures, no DBA required.

A Practical Playbook for Customer Success Teams

Here's how a customer success team of 3 people might use per-customer analytics in practice:

Monday morning ritual: Check the customer health dashboard. Look at accounts with declining WAU trends or high days-since-active. Flag for outreach.

Weekly account review: Filter the feature adoption panel by plan tier. Identify Growth accounts that haven't touched the advanced features yet these are candidates for a check-in call about whether they're getting value.

Renewal prep: Two weeks before a renewal, pull usage trends for the last 90 days. Bring actual numbers to the call instead of relying on gut feel.

Churn post-mortems: After an account churns, ask "what did their usage look like in the 60 days before they canceled?" Over time, patterns emerge that let you identify at-risk accounts earlier.

All of these involve asking questions of your database. The difference with AI-powered tools is that you can ask those questions in plain English, get results in seconds, and adapt the question as you learn more rather than waiting for each query to be written.